6. Manageability Considerations (Verwaltbarkeitsüberlegungen)

6. Manageability Considerations (Verwaltbarkeitsüberlegungen)

Dieser Abschnitt ist wie in [RFC5706] empfohlen strukturiert.

Bestehende BGP-Betriebsverfahren gelten. In diesem Dokument sind keine neuen Betriebsverfahren definiert. Es wird festgestellt, dass die in diesem Dokument vorhandenen NLRI-Informationen reine Daten auf Anwendungsebene tragen, die keine unmittelbare entsprechende Auswirkung auf den Weiterleitungszustand haben. Daher hat jede Änderung in den Erreichbarkeitsinformationen eine andere Auswirkung als reguläre BGP-Updates, die den Weiterleitungszustand für einen gesamten Router ändern müssen. Darüber hinaus wird erwartet, dass die Verteilung dieses NLRI von dedizierten Route Reflectors gehandhabt wird, die ein Maß an Isolierung und Fehlereindämmung zwischen verschiedenen NLRI-Typen bieten.

Die in Abschnitt 6.2.3 definierten Konfigurationsparameter SOLLTEN auf die folgenden Standardwerte initialisiert werden:

• Die Link-State NLRI-Fähigkeit ist für alle Nachbarn deaktiviert.

• Die maximale Rate, mit der Link-State NLRIs von Nachbarn angekündigt/zurückgezogen werden, ist auf 200 Updates pro Sekunde eingestellt.

Die vorgeschlagene Erweiterung wird nur zwischen BGP-Peers nach Fähigkeitsverhandlung aktiviert. Darüber hinaus können die Erweiterungen auf Basis einzelner Peers ein-/ausgeschaltet werden (siehe Abschnitt 6.2.3), sodass die Erweiterung schrittweise im Netzwerk eingeführt werden kann.

Die in diesem Dokument definierte Protokollerweiterung stellt keine neuen Anforderungen an andere Protokolle oder funktionale Komponenten.

Die Häufigkeit von Link-State NLRI-Updates könnte die reguläre BGP-Präfixverteilung beeinträchtigen. Ein Netzwerkbetreiber KANN eine dedizierte Route-Reflector-Infrastruktur verwenden, um Link-State NLRIs zu verteilen.

Die Verteilung von Link-State NLRIs SOLLTE auf eine einzige Verwaltungsdomäne beschränkt werden, die aus mehreren Bereichen innerhalb eines AS oder mehreren ASes bestehen kann.

Bestehende BGP-Verfahren gelten. Darüber hinaus SOLLTE eine Implementierung einem Betreiber ermöglichen:

• Nachbarn aufzulisten, mit denen der Sprecher Link-State NLRIs austauscht.

Die IDR-Arbeitsgruppe hat Teile der Management Information Base und YANG-Modelle zur Verwaltung und Überwachung von BGP-Sprechern und den Sitzungen zwischen ihnen dokumentiert und dokumentiert sie weiterhin. Es wird derzeit angenommen, dass die BGP-Sitzung, die BGP-LS ausführt, sich nicht wesentlich von jeder anderen BGP-Sitzung unterscheidet und mit denselben Datenmodellen verwaltet werden kann.

Wenn eine Implementierung von BGP-LS ein fehlerhaftes Attribut erkennt, dann MUSS sie die Aktion 'Attribute Discard' gemäß [RFC7606], Abschnitt 2, verwenden.

Eine Implementierung von BGP-LS MUSS die folgenden syntaktischen Prüfungen durchführen, um festzustellen, ob eine Nachricht fehlerhaft ist.

• Entspricht die Summe aller im BGP-LS-Attribut gefundenen TLVs der BGP-LS-Pfadattributlänge?

• Entspricht die Summe aller im BGP MP_REACH_NLRI-Attribut gefundenen TLVs der BGP MP_REACH_NLRI-Länge?

• Entspricht die Summe aller im BGP MP_UNREACH_NLRI-Attribut gefundenen TLVs der BGP MP_UNREACH_NLRI-Länge?

• Entspricht die Summe aller in einem Node-, Link- oder Prefix-Descriptor-NLRI-Attribut gefundenen TLVs dem Feld Total NLRI Length der Node-, Link- oder Prefix-Descriptors?

• Entspricht ein TLV fester Länge dem TLV-Length-Feld in diesem Dokument?

Eine Implementierung SOLLTE dem Betreiber ermöglichen, Nachbarn anzugeben, an die Link-State NLRIs angekündigt werden und von denen Link-State NLRIs akzeptiert werden.

Eine Implementierung SOLLTE dem Betreiber ermöglichen, die maximale Rate anzugeben, mit der Link-State NLRIs von Nachbarn angekündigt/zurückgezogen werden.

Eine Implementierung SOLLTE dem Betreiber ermöglichen, die maximale Anzahl von Link-State NLRIs anzugeben, die in der Routing Information Base (RIB) eines Routers gespeichert werden.

Eine Implementierung SOLLTE dem Betreiber ermöglichen, abstrahierte Topologien zu erstellen, die an Nachbarn angekündigt werden, und verschiedene Abstraktionen für verschiedene Nachbarn zu erstellen.

Eine Implementierung SOLLTE dem Betreiber ermöglichen, eine 64-Bit-Instance-ID zu konfigurieren.

Eine Implementierung SOLLTE dem Betreiber ermöglichen, ein Paar aus ASN und BGP-LS-Identifikatoren (Abschnitt 3.2.1.4) pro Flooding-Set zu konfigurieren, an dem der Knoten teilnimmt.

Nicht anwendbar.

Eine Implementierung SOLLTE die folgenden Statistiken bereitstellen:

• Gesamtzahl der gesendeten/empfangenen Link-State NLRI-Updates

• Anzahl der gesendeten/empfangenen Link-State NLRI-Updates pro Nachbar

• Anzahl der fehlerhaften empfangenen Link-State NLRI-Updates pro Nachbar

• Gesamtzahl der lokal originierten Link-State NLRIs

Diese Statistiken sollten als absolute Zählungen seit System- oder Sitzungsstart aufgezeichnet werden. Eine Implementierung KANN diese Informationen auch verbessern, indem sie in jedem Fall Spitzenwerte pro Sekunde aufzeichnet.

Ein Betreiber SOLLTE eine Importrichtlinie definieren, um eingehende Updates wie folgt zu begrenzen:

• Alle Updates von Verbraucher-Peers verwerfen.

Eine Implementierung MUSS die Möglichkeit haben, eingehende Updates zu begrenzen.