1. Introduction (Einleitung)

BGP Color-Aware Routing (BGP CAR) ist eine BGP-basierte Routing-Lösung zur Einrichtung von Ende-zu-Ende-absichtsbasierten Pfaden über ein Multi-Domain-Service-Provider-Transportnetzwerk. BGP CAR verteilt verschiedene Routen zu einem Zielnetzwerk-Endpunkt (z. B. einem Provider Edge (PE) Router) für verschiedene Absichten oder Farben. Eine Farbe ist ein von Null verschiedener 32-Bit-Ganzzahlwert, der mit einer Netzwerkabsicht (wie niedrige Kosten, niedrige Latenz, Vermeidung bestimmter Ressourcen, 5G-Netzwerk-Slice usw.) verbunden ist, wie in Abschnitt 2.1 von [RFC9256] definiert.

BGP CAR adressiert die Transport- und VPN-Problemstellung und Anforderungen, die in [INTENT-AWARE] beschrieben sind.

Zu diesem Zweck spezifiziert dieses Dokument zwei neue BGP SAFIs, genannt BGP CAR SAFI (83) und VPN CAR SAFI (84), zum Transport von Infrastrukturrouten zur Einrichtung von Transportpfaden. Sowohl CAR SAFI als auch VPN CAR SAFI sind auf IPv4 Unicast und IPv6 Unicast AFIs (AFI 1 und AFI 2) anwendbar. Die Verwendung dieser SAFIs mit anderen AFIs liegt außerhalb des Umfangs dieses Dokuments.

BGP CAR SAFI kann auf Transportgeräten in einem Provider-Netzwerk (Underlay) aktiviert werden, um farbsensitive Transport-/Infrastrukturpfade zwischen Provider-Netzwerken einzurichten. Ein Multi-Domain-Transportnetzwerk kann mehrere BGP Autonomous Systems (ASe) sowie mehrere IGP-Domänen innerhalb eines einzelnen BGP AS umfassen. BGP CAR SAFI kann auch in VPN Routing and Forwarding (VRF) auf PE-Routern zu peering Customer Edge (CE) Routern sowie auf Geräten innerhalb von Kundennetzwerken aktiviert werden. VPN CAR SAFI wird verwendet, um absichtsbasierte Routen, die von verschiedenen Kunden an PE-Routern empfangen werden, über das Provider-Netzwerk zu verteilen, während die Trennung potenziell überlappender Kundenadressräume aufrechterhalten wird. Somit ermöglicht die BGP CAR-Lösung die Einrichtung absichtsbasierter Transportpfade in einem Multi-Domain-Netzwerk, das Kunden- und Provider-Netzwerkdomänen umspannt.

Dieses Dokument definiert auch zwei BGP CAR-Routentypen für diesen Zweck.

BGP CAR Type-1 NLRI (E, C) unterstützt die Entstehung und Verteilung mehrerer farbsensitiver Routen zum selben Ziel-IP-Präfix für verschiedene Farben. Dies tritt in Szenarien auf, in denen ein Transportknoten (wie ein PE) eine gemeinsame IP-Adresse (wie eine Loopback-Adresse) für mehrere Absichtsankündigungen hat. Der Betreiber beabsichtigt, diese gemeinsame IP-Adresse sowohl als BGP Next Hop für Service-Routen als auch als Transport-Endpunkt für Datenpfade zu verwenden. Mehrere Routen zu dieser selben Adresse oder diesem Präfix sind erforderlich, um eindeutige Pfade für jede Absicht einzurichten. Ein Beispiel ist die Einrichtung mehrerer Label Switched Paths (LSPs) zu einem Egress-PE für MPLS oder Segment Routing over MPLS (SR-MPLS), einen für jede Absicht.

BGP CAR Type-2 NLRI (IP-Präfix oder E) unterstützt die Verteilung mehrerer farbsensitiver Routen zu einem Transportknoten in Szenarien, in denen der Betreiber eindeutige Netzwerk-IP-Adressblöcke für eine bestimmte Absicht festlegt und der Transportknoten für jede Absicht ein eindeutiges IP-Präfix oder eine Adresse zuweist. Ein Beispiel-Anwendungsfall sind absichtsspezifische Locators für Segment Routing over IPv6 (SRv6).

Diese BGP CAR absichtsbasierten Pfade werden dann von Ingress-Knoten (wie PEs) verwendet, um Traffic für Service-Routen zu steuern, die eine spezifische Absicht benötigen. Die Steuerung kann für den gesamten oder spezifischen Traffic zu einem Ziel erfolgen.

BGP CAR folgt dem flachen Routing-Modell, das von BGP für IP-Routing (BGP-IP) [RFC4271] oder BGP Labeled Unicast (BGP-LU) (SAFI 4 in [RFC8277]) verwendet wird, und erweitert es um Unterstützung für Absichtsbewusstsein, wodurch eine operative Erfahrung bereitgestellt wird, die mit diesen weitverbreiteten Transport-Routing-Technologien konsistent ist.

1.1. Terminology (Terminologie)

Intent (in routing) (Absicht (im Routing)):
Jedes Verhalten, das Routing oder Pfadauswahl beeinflusst, einschließlich jeder Kombination der folgenden Verhaltensweisen:

a. Topologische Pfadauswahl (z. B. Minimierung einer Metrik oder Vermeidung von Ressourcen)
b. Network Function Virtualization (NFV) Service-Einfügung (z. B. Service-Chain-Steuerung)
c. Per-Hop-Verhalten (z. B. 5G-Slicing)

Dies ist ein spezifischeres Konzept als Best-Effort in Bezug auf Routing, verglichen mit Intent als deklarative Abstraktion in [RFC9315].

Color (Farbe):
Ein von Null verschiedener 32-Bit-Ganzzahlwert, der mit einer Absicht (z. B. niedrige Kosten, niedrige Latenz oder Vermeidung bestimmter Ressourcen) verbunden ist, wie in Abschnitt 2.1 von [RFC9256] definiert. Die Farbzuweisung wird vom Betreiber verwaltet.

Colored service route (Farbige Service-Route):
Ein Egress-PE (z. B. E2) färbt seine BGP-Service- (z. B. VPN-) Route (z. B. V/v), um die Absicht anzugeben, die er für an V/v gebundenen Traffic anfordert. Die Farbe wird als BGP Color Extended Community [RFC9012] codiert, gemäß [RFC9256] verwendet, oder durch den Locator-Teil einer SRv6 Service-SID [RFC9252] dargestellt.

Color-aware path to (E2, C) (Farbsensitiver Pfad zu (E2, C)):
Ein Pfad zur Weiterleitung von Paketen zu E2, der die mit Farbe C verbundene Absicht erfüllt. Mehrere Technologien können einen farbsensitiven Pfad zu (E2, C) bereitstellen, wie SR Policy [RFC9256], IGP Flexible Algorithm [RFC9350] und BGP CAR (wie in diesem Dokument spezifiziert).

Color-aware route (E2, C) (Farbsensitive Route (E2, C)):
Eine verteilte oder signalisierte Route zum Aufbau eines farbsensitiven Pfads zu E2 für Farbe C.

Service route automated steering on color-aware path (Automatische Service-Routen-Steuerung auf farbsensitivem Pfad):
Ein Ingress-PE (oder ASBR) E1 steuert automatisch Traffic für eine C-gefärbte Service-Route V/v von E2 auf einen (E2, C) farbsensitiven Pfad. Wenn mehrere solche Pfade existieren, wird ein Präferenzschema verwendet, um den besten Pfad auszuwählen (z. B. IGP Flexible Algorithm bevorzugt gegenüber SR Policy, SR Policy bevorzugt gegenüber BGP CAR).

Color domain (Farbdomäne):
Eine Menge von Knoten, die dasselbe Farb-zu-Absicht-Mapping teilen, typischerweise unter einer einzigen Verwaltung. Die Menge kann in eine oder mehrere Netzwerkdomänen organisiert sein (IGP-Bereiche/-Instanzen innerhalb eines einzelnen BGP AS oder mehrere BGP ASe). Das Farb-zu-Absicht-Mapping auf Knoten wird über Konfiguration festgelegt. Farb-Remapping und -Filterung können an Farbdomänengrenzen auftreten. Siehe [INTENT-AWARE].

Resolution of a BGP CAR route (E, C) (Auflösung einer BGP CAR-Route (E, C)):
Eine Inter-Domain-BGP-CAR-Route (E, C) über N wird auf einem Intra-Domain-farbsensitiven Pfad (N, C) aufgelöst, wobei N der Next Hop der BGP CAR-Route ist.

Resolution versus steering (Auflösung versus Steuerung):
In Übereinstimmung mit der in SR Policy-Dokumenten ([RFC9256] Abschnitt 8) verwendeten Terminologie wird in diesem Dokument (Service-Routen-) Steuerung verwendet, um das Mapping von Traffic für eine Service-Route auf einen BGP CAR-Pfad zu beschreiben. Umgekehrt ist der Begriff Auflösung für das Mapping einer Inter-Domain-BGP-CAR-Route auf einen Intra-Domain-farbsensitiven Pfad reserviert.

Service steering (Service-Steuerung):
Service-Route mappt Traffic auf einen BGP CAR-Pfad (oder einen anderen farbsensitiven Pfad, z. B. SR Policy). Wenn kein farbsensitiver Pfad verfügbar ist, kann die lokale Policy auf eine farbunempfindliche Route/TE-Pfad (z. B. BGP-LU, RSVP-TE, IGP/LDP) mappen. Das Service-Steuerungskonzept ist unabhängig von der verwendeten Transporttechnologie. Abschnitt 3 beschreibt spezifische Service-Steuerungsmechanismen für MPLS, SR-MPLS und SRv6.

Intra-domain resolution (Intra-Domain-Auflösung):
BGP CAR-Route mappt auf einen Intra-Domain-farbsensitiven Pfad (z. B. SR Policy, IGP Flexible Algorithm, BGP CAR) oder farbunempfindliche Route/TE-Pfad (z. B. RSVP-TE, IGP/LDP, BGP-LU).

Transport network (Transportnetzwerk):
Ein Netzwerk, das mehrere kollaborierende Domänen umfasst, die von einem oder mehreren Betreibern verwaltet werden und Routing-Technologien (wie IP, MPLS und SR) verwenden, um Pakete weiterzuleiten und Konnektivität und andere Dienste bereitzustellen. In SR-Bereitstellungen befindet sich das Transportnetzwerk innerhalb der vertrauenswürdigen Domäne, wie in [RFC8402] definiert.

Transport layer (Transportschicht):
Bezieht sich auf die Underlay-Netzwerkschicht (z. B. MPLS LSPs zwischen PEs), die von einer Overlay- oder Service-Schicht (z. B. MPLS VPN) verwendet wird.

Transport RR (Transport-RR):
Ein BGP Route Reflector (RR), der verwendet wird, um Transport-/Underlay-Routen Intra-Domain oder Inter-Domain zu verteilen.

Service RR (Service-RR):
Ein BGP Route Reflector (RR), der verwendet wird, um Service-/Overlay-Routen Intra-Domain oder Inter-Domain zu verteilen.

Abbreviations (Abkürzungen):

• ABR: Area Border Router (Bereichsgrenzrouter)
• AFI: Address Family Identifier (Adressfamilienidentifikator)
• AIGP: Accumulated IGP Metric Attribute [RFC7311] (Kumuliertes IGP-Metrik-Attribut)
• ASBR: Autonomous System Border Router (Autonomes System-Grenzrouter)
• BGP-LU: BGP Labeled Unicast SAFI (SAFI-Wert 4 gemäß [RFC8277])
• BGP-IP: BGP IPv4/IPv6 Unicast SAFI (SAFI-Wert 1 gemäß [RFC4760] und [RFC4271])
• BR: Border Router (Grenzrouter, für IGP-Bereich (ABR) oder BGP Autonomous System (ASBR))
• Color-EC: BGP Color Extended Community [RFC9012] (BGP-Farb-Extended-Community)
• E: Generische Darstellung eines Transport-Endpunkts, z. B. PE, ABR oder ASBR
• LCM-EC: BGP Local Color Mapping Extended Community (BGP-Lokales-Farb-Mapping-Extended-Community)
• NLRI: Network Layer Reachability Information [RFC4271] (Netzwerkschicht-Erreichbarkeitsinformation)
• P node: Intra-Domain-Transport-Router
• RD: Route Distinguisher (Routenunterscheider)
• RR: Route Reflector (Routenreflektor)
• T-RR: Transport Route Reflector (Transport-Routenreflektor)
• S-RR: Service Route Reflector (Service-Routenreflektor)
• SAFI: Subsequent Address Family Identifier (Nachfolgender Adressfamilienidentifikator)
• TEA: Tunnel Encapsulation Attribute [RFC9012] (Tunnel-Kapselungsattribut)
• V/v, W/w: Generische Darstellung von Service-Routen (die Präfix-/Maskenlänge anzeigt), unabhängig von AFI/SAFI oder tatsächlicher NLRI-Codierung

1.2. Illustration (Veranschaulichung)

Das Folgende ist eine kurze Veranschaulichung bemerkenswerter Merkmale der BGP CAR-Lösung.

+-------------+      +-------------+      +-------------+
|             |      |             |      |             | V/v with C1
|----+        |------|             |------|        +----|/
| E1 |        |      |             |      |        | E2 |\
|----+        |      |             |      |        +----| W/w with C2
|             |------|             |------|             |
|  Domain 1   |      |   Domain 2  |      |   Domain 3  |
+-------------+      +-------------+      +-------------+

Abbildung 1: Veranschaulichung der BGP CAR-Lösung

Alle Knoten sind Teil eines Inter-Domain-Netzwerks unter einer einzigen Autorität mit konsistentem Farb-zu-Absicht-Mapping:

• C1 mappt auf "niedrige Latenz"

  • Flex-Algo 1 mappt auf "niedrige Latenz", daher auf C1

• C2 mappt auf "niedrige Latenz und Vermeidung von Ressource R"

  • Flex-Algo 2 mappt auf "niedrige Latenz und Vermeidung von Ressource R", daher auf C2

E1 empfängt zwei Service-Routen von E2:

• V/v mit BGP Color-EC C1
• W/w mit BGP Color-EC C2

E1 hat die folgenden farbsensitiven Pfade:

• (E2, C1) bereitgestellt durch BGP CAR mit domänenspezifischer Unterstützung wie folgt:

  • Domäne 1: über IGP FA1
  • Domäne 2: über SR Policy gebunden an Farbe C1
  • Domäne 3: über IGP FA1

• (E2, C2) bereitgestellt durch SR Policy

E1 steuert automatisch Traffic für empfangene Service-Routen wie folgt:

• V/v über (E2, C1) bereitgestellt durch BGP CAR
• W/w über (E2, C2) bereitgestellt durch SR Policy

Beispieleigenschaften:

• Nutzung von BGP Color-EC

  • Service-Routen werden unter Verwendung der weit verbreiteten BGP Color Extended Community [RFC9012] gefärbt, um Absicht anzufordern

• (E, C) Automatische Steuerung

  • V/v und W/w werden automatisch auf geeignete farbsensitive Pfade gesteuert

• Nahtlose Koexistenz von BGP CAR und SR Policy

  • V/v gesteuert auf farbsensitiven Pfad bereitgestellt durch BGP CAR
  • W/w gesteuert auf farbsensitiven Pfad bereitgestellt durch SR Policy

• Nahtlose Interoperabilität von BGP CAR und SR Policy

  • V/v gesteuert auf BGP CAR-Pfad, der sich selbst innerhalb von Domäne 2 auf eine an V/vs Farbe gebundene SR Policy auflöst

Zusätzliche Eigenschaften:

• MPLS-Datenebene: Für 300k PEs und 5 Farben stellt die BGP CAR-Lösung sicher, dass kein einzelner Knoten Datenebenen-Skalierung in der Größenordnung von entfernten PEs * C unterstützen muss (Abschnitt 5). Dies würde andernfalls die MPLS-Datenebenen-Fähigkeiten überschreiten.

• Steuerungsebene: Wenn ein Knoten nicht an diesem farbsensitiven Pfad teilnimmt, SOLLTE er den (E, C)-Pfad NICHT installieren.

• Inkonsistentes Farb-Absicht-Mapping: Die Lösung unterstützt BGP CAR-Routen-Signalisierung über verschiedene Farbdomänen hinweg (Abschnitt 2.8).

Hauptvorteile dieses Modells sind:

• Nutzung von BGP Color-EC [RFC9012] für Service-Routen-Färbung
• Definition der automatischen Service-Steuerung: C-gefärbte Service-Route V/v von E2 steuert auf farbsensitiven Pfad (E2, C)
• Definition des BGP CAR-Pfaddatenmodells: (E, C)
  • Natürliche Erweiterung des BGP-IP/BGP-LU-Datenmodells (E)
  • Konsistent mit SR Policy-Datenmodell
• Definition der rekursiven Auflösung für BGP CAR-Routen: BGP CAR (E2, C)-Route über N löst sich auf farbsensitivem Pfad (N, C) auf, der selbst durch BGP CAR oder über eine andere farbsensitive Routing-Lösung (z. B. SR Policy, IGP Flexible Algorithm) bereitgestellt werden kann
• Explizite Definition mehrerer Transport-Kapselungen (z. B. MPLS, SR, SRv6, IP)

1.3. Requirements Language (Anforderungssprache)

Die Schlüsselwörter "MUST (MUSS)", "MUST NOT (DARF NICHT)", "REQUIRED (ERFORDERLICH)", "SHALL (SOLL)", "SHALL NOT (SOLL NICHT)", "SHOULD (SOLLTE)", "SHOULD NOT (SOLLTE NICHT)", "RECOMMENDED (EMPFOHLEN)", "NOT RECOMMENDED (NICHT EMPFOHLEN)", "MAY (KANN)" und "OPTIONAL (OPTIONAL)" in diesem Dokument sind wie in BCP 14 [RFC2119] [RFC8174] beschrieben zu interpretieren, wenn und nur wenn sie in Großbuchstaben erscheinen, wie hier gezeigt.

---