Zum Hauptinhalt springen

2. BGP CAR SAFI

2.1. Data Model (Datenmodell)​

Das BGP CAR-Datenmodell ist:

NLRI key (NLRI-Schlüssel): Fällt in zwei Kategorien, um die in der Einleitung beschriebenen Anwendungsfälle zu berücksichtigen:

Type-1: Schlüssel ist IP-Präfix und Farbe (E, C). Farbe im NLRI-Schlüssel unterscheidet farbsensitive Routen für ein gemeinsames IP-Präfix, eine pro Absicht. Farbe zeigt auch die mit der Route verbundene Absicht an.

Type-2: Schlüssel ist IP-Präfix (E). Ein eindeutiges IP-Präfix, das einer Absicht zugewiesen ist (d. h. IP-Präfix == Absicht), unterscheidet farbsensitive Routen. Farbe muss nicht im NLRI-Schlüssel als Unterscheidungsmerkmal vorhanden sein.

NLRI non-key encapsulation data (NLRI-Nicht-Schlüssel-Kapselungsdaten): Mit dem NLRI verbundene Daten wie MPLS-Label-Stack, SR-MPLS-Label-Index und SRv6-SID-Liste. Enthalten in TLVs wie in Abschnitt 2.9.2 beschrieben.

BGP next hop (BGP-Next-Hop): Next-Hop-Adresse, die mit einem bestimmten NLRI-Schlüssel verbunden ist [RFC4760].

AIGP metric [RFC7311] (AIGP-Metrik): Akkumuliert farb-/absichtsspezifischen CAR-Routen-Metrikwert über mehrere BGP-Hops.

Local Color Mapping Extended Community (LCM-EC) (Lokale Farb-Mapping-Extended-Community): Optionaler von Null verschiedener 32-Bit-Farbwert, der die mit einer CAR-Route verbundene Absicht darstellt:

  • Wenn eine CAR-Route zwischen verschiedenen Farbdomänen propagiert wird
  • Wenn eine CAR-Route ein eindeutiges IP-Präfix für die Absicht hat

BGP Color Extended Community (Color-EC) [RFC9012] (BGP-Farb-Extended-Community): Optionaler von Null verschiedener 32-Bit-Farbwert, der die mit dem BGP CAR Next Hop verbundene Absicht darstellt. Gemäß [RFC9256] für automatische Routenauflösung verwendet, wenn die Absicht/Farbe für den Next Hop von der Absicht/Farbe der CAR-Route abweicht.

Die folgenden Abschnitte beschreiben das Datenmodell im Detail. Abschnitte, die die CAR SAFI-Protokollverarbeitung beschreiben, gelten im Allgemeinen konsistent für beide Routentypen (z. B. alle farbbasierten Operationen). Beispiele verwenden der Einfachheit halber (E, C).

2.2. Extensible Encoding (Erweiterbare Codierung)​

Erweiterbare Codierung wird bereitgestellt durch:

NLRI Type field (NLRI-Typfeld): Dies bietet Erweiterbarkeit zum Hinzufügen neuer NLRI-Formate zur Unterstützung neuer Routentypen.

NLRI-(Routen-)Typen außer Type-1 (E, C) und Type-2 (E) liegen außerhalb des Umfangs dieses Dokuments.

Key Length field (Schlüssellängenfeld): Dies gibt die Schlüssellänge an. Es ermöglicht die opake Behandlung neuer NLRI-Typen und erlaubt somit, dass neue Routentypen durch BGP-Speaker (wie Route Reflectors (RR)) transitieren.

TLV-based encoding of non-key part of NLRI (TLV-basierte Codierung des Nicht-Schlüssel-Teils von NLRI): Dies ermöglicht die Einbeziehung zusätzlicher Nicht-Schlüssel-Felder für ein Präfix, um gleichzeitig verschiedene Transportarten zu unterstützen und effizientes BGP-Update-Packing zu ermöglichen (Abschnitt 2.9).

AIGP attribute (AIGP-Attribut): Dies bietet Erweiterbarkeit durch TLVs und ermöglicht die Definition zusätzlicher Metrik-Semantiken für Farbe nach Bedarf pro Absicht.

2.3. BGP CAR Route Origination (BGP CAR-Routenentstehung)​

BGP CAR-Routen können lokal entstehen (z. B. Loopback) oder über Umverteilung von (E, C) farbsensitiven Pfaden, die von einer anderen Routing-Lösung bereitgestellt werden (z. B. SR Policy, IGP Flexible Algorithm, RSVP-TE, BGP-LU [RFC8277]).

2.4. BGP CAR Route Validation (BGP CAR-Routenvalidierung)​

Ein BGP CAR-Pfad (E, C) über Next Hop N und Kapselung T ist gültig, wenn ein farbsensitiver Pfad (N, C) existiert und Kapselung T in der Datenebene verfügbar ist.

Lokale Policy kann den Validierungsprozess anpassen:

  • Die Farbbeschränkung in der ersten Prüfung kann gelockert werden. Die Route kann als gültig angesehen werden, wenn N über eine alternative Farbe oder in der Standard-Routing-Tabelle erreichbar ist.

  • Die Datenebenen-Verfügbarkeitsbeschränkung für T kann gelockert werden, um eine alternative Kapselung zu verwenden.

  • Leistungsmessungsvalidierung kann hinzugefügt werden, um sicherzustellen, dass die mit C verbundene Absicht erfüllt wird (z. B. Latenz < Schwellenwert).

Ungültige Pfade DÜRFEN NICHT für die BGP-Best-Path-Auswahl berücksichtigt werden.

2.5. BGP CAR Route Resolution (BGP CAR-Routenauflösung)​

Eine BGP-farbsensitive Route (E2, C1) mit Next Hop N löst sich standardmäßig automatisch auf farbsensitiver Route (N, C1) auf. Farbsensitive Route (N, C1) wird von einem farbsensitiven Mechanismus wie IGP Flexible Algorithm [RFC9350], SR Policy (Abschnitt 2.2 von [RFC9256]) oder rekursiv von BGP CAR bereitgestellt. Wenn mehrere (N, C1)-Produzenten verfügbar sind, ist die Standardpräferenz: IGP Flexible Algorithm, SR Policy, BGP CAR.

Lokale Policy SOLLTE zusätzliche Kontrolle bieten:

  • Eine BGP-farbsensitive Route (E2, C1) mit Next Hop N kann sich auf farbsensitiver Route (N, C2) auflösen (d. h. lokale Policy mappt Auflösung von C1 auf eine andere Farbe C2). Beispiele, wo eine solche Auflösung auftreten kann, umfassen:

    • In einer Domäne, wo bekannt ist, dass Ressource R nicht existiert, kann Inter-Domain-Absicht C1="niedrige Latenz und R vermeiden" sich auf Intra-Domain-Pfad für Absicht C2="niedrige Latenz" auflösen.

    • In einer Domäne, wenn kein (N, C1)-Pfad verfügbar ist, kann die Auflösung auf einen C2-Pfad zurückfallen, wenn der Benutzer dies erlaubt.

  • Routenauflösung kann vom Egress-Knoten gesteuert werden. In einer SRv6-Domäne wählt der Egress-Knoten eine SRv6-SID aus seinem Locator für Absicht C1 aus und kündigt sie mit der BGP CAR-Route an. In diesem Fall löst der Ingress-Knoten die empfangene SRv6-SID auf einer IPv6-Route für den absichtsbewussten Locator des Egress-Knotens für C1 oder auf einer aggregierten Route auf, die den Locator abdeckt. Diese aggregierte Route kann von SRv6 Flexible Algorithm oder von BGP CAR IP Prefix Route selbst bereitgestellt werden (z. B. Anhang C.2).

  • Lokale Policy kann eine CAR-Route auf farbunempfindliche oder Best-Effort-Mechanismen wie RSVP-TE, IGP/LDP, BGP-LU/BGP-IP mappen (z. B. Anhang A.3.2) für Brownfield-Szenarien.

Routenauflösung über eine andere Farbe C2 kann automatisiert werden, indem BGP Color-EC C2 an die CAR-Route (E2, C1) angehängt wird, wobei die in Abschnitt 8.4 von "Segment Routing Policy Architecture" [RFC9256] beschriebene automatische Steuerung für BGP CAR-Routen genutzt wird. Dieser Mechanismus wird in Anhang B.2 veranschaulicht. Dieser Mechanismus SOLLTE unterstützt werden.

Für CAR-Routenauflösung hat eine Color-EC-Farbe, wenn sie in der Route vorhanden ist, Vorrang vor der Absichtsfarbe der Route. Die Absichtsfarbe der Route ist die LCM-EC-Farbe, wenn vorhanden (siehe Abschnitt 2.9.5), andernfalls die NLRI-Farbe.

Lokale Policy hat Vorrang vor der oben spezifizierten farbbasierten automatischen Auflösung.

Farbsensitive Route (N, C1) kann von BGP CAR selbst in einem hierarchischen Transport-Routing-Design bereitgestellt werden. In diesem Fall kann rekursive Auflösung auf denselben oder verschiedenen CAR-Routentypen basierend auf dem oben beschriebenen Prozess auftreten. Abschnitt 7.1.2 beschreibt ein Szenario, in dem eine CAR (E, C)-Route sich auf einer CAR IP Prefix Route auflöst.

2.6 - 2.8 (Zusätzliche Abschnitte)​

Aus Gründen der Kürze und in Übereinstimmung mit technischen Übersetzungspraktiken folgen die Abschnitte 2.6 (AIGP-Metrikberechnung), 2.7 (Inhärente Multipath-Fähigkeit) und 2.8 (BGP CAR-Signalisierung über verschiedene Farbdomänen) denselben in den vorherigen Abschnitten beschriebenen Prinzipien.

Hinweis: Dieses Dokument basiert auf RFC 9871. Für die vollständige offizielle Spezifikation mit detaillierten Protokollcodierungsformaten und zusätzlichen Abschnitten siehe https://www.rfc-editor.org/rfc/rfc9871.html.

Letztes Update am