Segment Routing Design: SRGB, SIDs, Policies und Failure Handling

Segment Routing Design ist im Telco- und Provider-Umfeld zu einem zentralen Architekturthema geworden, weil Segment Routing (SR) Traffic Engineering, Pfadsteuerung und Resilienz moderner und häufig betrieblich einfacher umsetzen kann als viele klassische Ansätze. Gleichzeitig ist SR kein „Plug-and-Play“-Feature: Ein robustes Design erfordert klare Entscheidungen zu SRGB, SID-Typen, Policy-Modellen und Failure Handling. Wer Segment Routing nur „einschaltet“, ohne SRGB-Planung, konsistente SID-Vergabe, nachvollziehbare Policies und messbare Störfallmechanismen, riskiert unvorhersehbare Pfade, schwer zu erklärende Traffic-Shifts und steigende Betriebskosten. Carrier-Grade SR-Design bedeutet daher: Underlay stabil halten, SR als deterministisches Pfadwerkzeug nutzen, Failure Domains bewusst schneiden und eine Telemetry-Strategie etablieren, die Pfadwahl und Konvergenz sichtbar macht. Dieser Artikel erklärt verständlich, wie SRGB und SIDs geplant werden, wie Policies sauber modelliert werden und wie Failure Handling in der Praxis funktioniert – mit Fokus auf Skalierung, Betriebsfähigkeit und nachvollziehbarem Verhalten.

Segment Routing im Überblick: Was SR im Kern verändert

Segment Routing beschreibt Pfade durch eine Sequenz von „Segmenten“. Diese Segmente sind Anweisungen, die bestimmte Netzressourcen repräsentieren, etwa einen Knoten (Node), eine Adjazenz (Adjacency) oder eine Service-/Policy-Intention. Der entscheidende Unterschied zu vielen klassischen TE-Ansätzen ist: Die Pfadintention wird stärker am Rand (Ingress) formuliert, während Transit-Knoten möglichst standardisiert weiterleiten. Das unterstützt das Carrier-Grade Ziel, den Core stabil und „service-agnostisch“ zu betreiben.

• Pfad als Segmentliste: Der Ingress setzt eine Segment-Sequenz, die den gewünschten Weg beschreibt.
• Transit bleibt einfach: P-Router schalten Segmente, ohne kundenspezifische Zustände zu halten.
• Traffic Engineering: Pfadsteuerung wird policy-basiert und besser automatisierbar.
• Resilienz: Backup-Pfade und lokale Reparaturen lassen sich gezielt planen.

SR-MPLS und SRv6: Designprinzipien bleiben ähnlich

Ob SR über MPLS (SR-MPLS) oder über IPv6 (SRv6) umgesetzt wird, hängt von Plattformen und Strategie ab. Die Kernfragen im Design sind jedoch vergleichbar: Welche Segmente gibt es, wie werden sie nummeriert/verwaltet, wie werden Policies definiert, und wie reagiert das Netz bei Fehlern?

SRGB: Der Nummernraum, der Designfehler teuer macht

Die SRGB (Segment Routing Global Block) ist der globale SID-Nummernraum, aus dem Node-SIDs typischerweise abgeleitet werden. In SR-MPLS ist SRGB besonders wichtig, weil SIDs häufig als MPLS-Labels umgesetzt werden. Ein sauberer SRGB-Plan ist eine Grundvoraussetzung für Skalierung und Interoperabilität: Wenn SRGBs inkonsistent sind, wird Troubleshooting schwer und Migrationen werden riskanter.

• Global konsistent: Idealerweise ist die SRGB netzweit einheitlich, damit Node-SIDs überall gleich interpretiert werden.
• Reserve einplanen: Genug Platz für Wachstum, neue Regionen und Sonderfälle.
• Dokumentiert und versioniert: SRGB ist ein „Netzstandard“, kein Device-Detail.
• Domänen bewusst behandeln: Bei Multi-Domain-Designs müssen SRGB-Grenzen klar definiert sein.

SRGB-Strategie: Einfach halten, um Betrieb zu vereinfachen

In vielen Carrier-Netzen hat sich eine einfache Regel bewährt: Eine SRGB für die gesamte SR-Domäne und klare Reserven für Erweiterungen. Sonder-SRGBs pro Region oder pro Plattform erhöhen Varianten und erschweren die Betriebserklärung, besonders bei Interop- und Migrationsphasen.

SIDs verstehen: Node-SID, Adjacency-SID, Anycast-SID und mehr

SIDs sind die Bausteine von SR-Pfaden. Ein robustes Segment Routing Design definiert, welche SID-Typen genutzt werden und wofür. Zu viele SID-Varianten erhöhen Komplexität, zu wenige können TE-Use-Cases einschränken. In der Praxis hat sich eine Mischung bewährt: Node-SIDs als Standard, Adjacency-SIDs für präzise Kantensteuerung, und Anycast-SIDs für resiliente Service- und Gateway-Patterns.

• Node-SID: Repräsentiert einen Knoten; führt entlang des IGP-Kürzestpfads zum Zielknoten.
• Adjacency-SID: Repräsentiert eine konkrete Link-Kante; erlaubt explizite Pfadführung.
• Anycast-SID: Eine SID, die mehrere Knoten announcen; unterstützt Gateway-/Service-Patterns.
• Service/Policy-SIDs: Je nach Architektur können zusätzliche SIDs Service-Intentionen abbilden.

Designregel: Node-SIDs als Default, Adjacency-SIDs als Skalpell

Node-SIDs sind betrieblich am einfachsten, weil sie eng am IGP-Modell bleiben. Adjacency-SIDs sind mächtig, erhöhen aber den Planungs- und Testaufwand, weil sie sehr spezifisch sind. Ein guter Ansatz ist: Node-SIDs decken die meisten Pfade ab; Adjacency-SIDs werden gezielt für kritische Pfadsegmente eingesetzt, etwa für physische Diversität oder Latenzgarantien.

SID-Planung: Konsistenz, Naming und Automatisierung

SID-Planung ist in großen Netzen ein Governance-Thema. Ohne klare Regeln entstehen Inkonsistenzen, die später Migration, Troubleshooting und Audit erschweren. Deshalb sollten SIDs wie IP-Adressierung behandelt werden: mit Templates, Reserven, eindeutigen Zuordnungen und einem Ausnahmeprozess.

• Deterministische Vergabe: SIDs sollten aus einem konsistenten Schema ableitbar sein (z. B. aus Loopback- oder Node-IDs).
• Dokumentation: SID-Zuordnung muss schnell nachvollziehbar sein, ohne „Gerätewissen“.
• Versionierung: Änderungen am SID-Schema sind rare, kontrollierte Events.
• Automation-Readiness: SID-Policies müssen templatefähig sein, sonst explodiert OPEX.

Ein einfaches Schema-Denkmodell

Viele Provider nutzen ein Schema, bei dem die Node-SID aus einer eindeutigen Node-ID abgeleitet wird. In abstrakter Form:

$\mathrm{NodeSID}=\mathrm{SRGB\_Base}+\mathrm{NodeID}$

Dieses Modell ist bewusst vereinfacht, zeigt aber das Prinzip: SIDs werden deterministisch, konsistent und skalierbar vergeben.

SR Policies: Intent statt Mikromanagement

SR Policies definieren, wie Traffic gelenkt werden soll. In der Praxis sind SR Policies ein „Intent“-Werkzeug: Sie beschreiben Pfadklassen (z. B. Low-Latency, High-Capacity, High-Resilience) und setzen diese auf Flows oder Serviceklassen um. Damit wird Traffic Engineering planbarer und besser operationalisierbar, sofern Policies standardisiert und getestet sind.

• Low-Latency Policies: Pfade, die Latenzbudgets priorisieren (kurze Trassen, wenige Hops).
• High-Capacity Policies: Pfade, die Auslastung verteilen und Bulk-Traffic aufnehmen.
• Resilience Policies: Pfade mit physischer Diversität und robusten Alternativen.
• Maintenance Policies: Temporäre Pfadintentionen zum Traffic-Drain während Wartung.

Policy-as-Code: Der Schlüssel zu Skalierung

SR Policies werden schnell zur größten Stellschraube im Netz. Deshalb sollten sie wie Software behandelt werden: versioniert, reviewed, getestet und in Wellen ausgerollt. Das erhöht Sicherheit, reduziert Fehlkonfigurationen und macht SR auditierbar.

Failure Handling: Was passiert bei Link-, Node- und Trassen-Ausfällen?

Carrier-Grade Segment Routing ist nur dann erfolgreich, wenn Failure Handling nicht dem Zufall überlassen wird. Ein robustes Design definiert konkrete Störfallszenarien, die das Netz abfangen muss, und legt fest, wie schnell und wie stabil die Umschaltung erfolgen soll. Dabei ist entscheidend: Umschaltung muss nicht nur existieren, sondern messbar innerhalb definierter Grenzen stattfinden.

• Link Failure: Ein Link fällt aus; Traffic muss auf alternative Pfade wechseln, ohne Hotspots zu erzeugen.
• Node Failure: Ein Knoten fällt aus; Pfade müssen ihn zuverlässig umgehen.
• Trassenunterbrechung: Mehrere Links gleichzeitig betroffen; Diversität wird auf die Probe gestellt.
• Degradation: Nicht nur „down“, sondern steigende Loss/Latency durch Überlast müssen erkannt werden.

Local Repair vs. End-to-End Reroute: Geschwindigkeit und Vorhersehbarkeit

In vielen Designs ist eine schnelle lokale Reparatur (local repair) attraktiv, weil sie Umschaltzeiten reduziert. Gleichzeitig muss der resultierende Pfad in die globale Policy-Logik passen: Ein schneller lokaler Umweg ist nutzlos, wenn er Störfallkapazität sprengt oder Latenzbudgets verletzt. Ein gutes Design kombiniert daher schnelle Reparaturmechanismen mit klaren Policy-Grenzen und Telemetry, die den Pfadwechsel sichtbar macht.

Resilienz braucht Kapazität: Störfallreserve als Designregel

SR kann Pfade steuern, aber keine fehlende Reserve „wegzaubern“. Wenn der Ausfall eines Links den verbleibenden Pfad überlastet, entstehen Drops und SLA-Verletzungen, obwohl SR korrekt umgeschaltet hat. Deshalb gehört Störfallkapazität als feste Regel in jedes SR-Design: Reservequoten pro Linkklasse, Upgrade-Trigger und Serviceklassenpriorisierung.

• N-1 Denken: Kapazität so planen, dass relevante Ausfallfälle tragbar sind.
• Serviceklassen: Kritische Flows priorisieren, Best-Effort kontrolliert degradieren.
• Upgrade-Trigger: Auslastung, Queue-Drops und Latenzsprünge als klare Auslöser.
• Shared Risk: Diversität real prüfen, sonst ist der Backup-Pfad nur „logisch“ anders.

Ein praktisches Störfallmodell

Als Denkmodell kann man annehmen, dass im Fehlerfall ein definierter Anteil der Last auf verbleibende Pfade fällt. Vereinfacht:

$\mathrm{Headroom}\ge \mathrm{Traffic}\times \mathrm{Failover\_Faktor}$

Der $\mathrm{Failover\_Faktor}$ hängt von Topologie, SR Policies und Failure Domains ab. Entscheidend ist, dass er im Design explizit berücksichtigt wird.

Observability: SR-Pfade müssen erklärbar sein

Segment Routing verändert Troubleshooting: Traffic folgt Policies und Segmentlisten. Betriebsteams müssen daher schnell erkennen können, welche Policy aktiv ist, welchen Pfad sie tatsächlich nutzt und ob Pfadwechsel stattgefunden haben. Ohne diese Sichtbarkeit entstehen „mystische“ Fehlerbilder: Alles ist „up“, aber Nutzer erleben Latenzspitzen oder sporadische Drops.

• Policy Visibility: Welche SR Policy ist pro Flow/Serviceklasse aktiv?
• Path Visibility: Welche Segmente werden genutzt, wie verteilt sich Traffic über ECMP?
• Performance KPIs: Latenz, Jitter, Loss pro Pfadklasse und Region, historisiert.
• Failure Events: Zeitstempel für Umschaltungen, Konvergenzzeiten, Root-Cause-Korrelation.

Evidence-by-Design: SR als auditierbarer Bestandteil der Architektur

SR-Design wird auditierbar, wenn Policies versioniert sind, Changes dokumentiert, Tests regelmäßig durchgeführt und Telemetry-Daten historisiert werden. Das reduziert nicht nur Auditstress, sondern verbessert die Betriebssicherheit, weil Entscheidungen nicht auf Bauchgefühl basieren.

Design-Governance: Wie man Komplexität verhindert

Segment Routing kann Komplexität reduzieren, aber nur, wenn das Design Variabilität begrenzt. Ohne Governance entstehen zu viele Policies, zu viele Sonderpfade und zu viele Ausnahmen. Das macht das Netz schwer zu verstehen und teuer im Betrieb.

• Wenige Pfadklassen: Statt unzähliger individueller Policies wenige standardisierte Profile.
• Rollenmodell: Core-P, Core-Edge, Metro-Edge, Service-Edge – mit klaren SR-Regeln pro Rolle.
• Ausnahmen kontrollieren: Begründung, Owner, Testplan, idealerweise Ablaufdatum.
• Wellen-Rollout: Änderungen zuerst klein testen, dann skalieren, Rollback immer möglich.

Migration: SR schrittweise einführen

In Telco-Netzen wird SR selten als Big Bang eingeführt. Ein bewährtes Vorgehen ist: Underlay stabilisieren, SRGB und SIDs konsistent planen, dann SR für ausgewählte TE-Use-Cases aktivieren (z. B. Maintenance-Drain, Low-Latency-Pfade). Erst wenn Observability und Betrieb reif sind, wird SR flächig für mehr Services genutzt.

Praktische Leitlinien für robustes Segment Routing Design

• SRGB konsistent halten: Einfache, netzweite SRGB-Strategie mit Reserven.
• Node-SIDs standardisieren: Deterministisches Schema, das Skalierung und Troubleshooting erleichtert.
• Adjacency-SIDs gezielt nutzen: Nur dort, wo echte Mehrwerte entstehen (Diversität, kritische Kanten).
• Policies als Profile: Low-Latency, High-Capacity, Resilience, Maintenance – wenige, klare Klassen.
• Failure Handling testen: Link/Node/Trasse und Wartungsszenarien messen, nicht vermuten.
• Störfallreserve planen: Kapazität gegen definierte Ausfälle dimensionieren.
• Telemetry priorisieren: Pfad- und Policy-Transparenz plus Performance-KPIs als Standard.
• Governance durchsetzen: Versionierung, Reviews, Wellen-Rollouts, Ausnahmen streng kontrollieren.