Appendix F. Implementation Recommendations (Implementierungsempfehlungen)

Dieser Abschnitt präsentiert einige Implementierungsempfehlungen.

Appendix F.1. Multiple Networks Per Message (Mehrere Netzwerke pro Nachricht)

Das BGP-Protokoll ermöglicht es, mehrere Adresspräfixe mit denselben Pfadattributen in einer Nachricht anzugeben. Die Verwendung dieser Fähigkeit wird dringend empfohlen. Mit einem Adresspräfix pro Nachricht gibt es eine erhebliche Erhöhung des Overheads beim Empfänger. Nicht nur der System-Overhead steigt aufgrund des Empfangs mehrerer Nachrichten, sondern auch der Overhead des Scannens der Routing-Tabelle für Updates an BGP-Peers und andere Routing-Protokolle (und das Senden der zugehörigen Nachrichten) wird mehrfach verursacht.

Eine Methode zum Erstellen von Nachrichten, die viele Adresspräfixe pro Pfadattributset aus einer Routing-Tabelle enthalten, die nicht auf Pro-Pfadattributset-Basis organisiert ist, besteht darin, viele Nachrichten zu erstellen, während die Routing-Tabelle gescannt wird. Wenn jedes Adresspräfix verarbeitet wird, wird eine Nachricht für das zugehörige Pfadattributset zugewiesen, falls es nicht existiert, und das neue Adresspräfix wird hinzugefügt. Wenn eine solche Nachricht existiert, wird das neue Adresspräfix angehängt. Wenn der Nachricht der Platz fehlt, um das neue Adresspräfix zu halten, wird sie übertragen, eine neue Nachricht wird zugewiesen und das neue Adresspräfix wird in die neue Nachricht eingefügt. Wenn die gesamte Routing-Tabelle gescannt wurde, werden alle zugewiesenen Nachrichten gesendet und ihre Ressourcen freigegeben. Maximale Kompression wird erreicht, wenn alle durch die Adresspräfixe abgedeckten Ziele ein gemeinsames Set von Pfadattributen teilen, was es ermöglicht, viele Adresspräfixe in einer 4096-Byte-Nachricht zu senden.

Beim Peering mit einer BGP-Implementierung, die mehrere Adresspräfixe nicht in eine Nachricht komprimiert, kann es notwendig sein, Maßnahmen zu ergreifen, um den Overhead durch die Flut von empfangenen Daten zu reduzieren, wenn ein Peer erworben wird oder wenn eine signifikante Netzwerktopologieänderung auftritt. Eine Methode hierfür ist die Begrenzung der Update-Rate. Dies eliminiert das redundante Scannen der Routing-Tabelle, um Flash-Updates für BGP-Peers und andere Routing-Protokolle bereitzustellen. Ein Nachteil dieses Ansatzes ist, dass er die Propagierungslatenz von Routing-Informationen erhöht. Durch die Wahl eines minimalen Flash-Update-Intervalls, das nicht viel größer ist als die Zeit, die zum Verarbeiten der mehreren Nachrichten benötigt wird, sollte diese Latenz minimiert werden. Eine bessere Methode wäre es, alle empfangenen Nachrichten zu lesen, bevor Updates gesendet werden.

Appendix F.2. Reducing Route Flapping (Reduzierung von Route Flapping)

Um übermäßiges Route Flapping zu vermeiden, sollte (SHOULD) ein BGP-Speaker, der ein Ziel zurückziehen und ein Update über eine spezifischere oder weniger spezifische Route senden muss, diese in derselben UPDATE-Nachricht kombinieren.

Appendix F.3. Path Attribute Ordering (Pfadattribut-Reihenfolge)

Implementierungen, die Update-Nachrichten kombinieren (wie oben in Abschnitt 6.1 beschrieben), bevorzugen möglicherweise, dass alle Pfadattribute in einer bekannten Reihenfolge präsentiert werden. Dies ermöglicht es ihnen, Sets von Attributen aus verschiedenen Update-Nachrichten schnell zu identifizieren, die semantisch identisch sind. Um dies zu erleichtern, ist es eine nützliche Optimierung, die Pfadattribute nach Typcode zu ordnen. Diese Optimierung ist völlig optional.

Appendix F.4. AS_SET Sorting (AS_SET-Sortierung)

Eine weitere nützliche Optimierung, die durchgeführt werden kann, um diese Situation zu vereinfachen, ist die Sortierung der in einem AS_SET gefundenen AS-Nummern. Diese Optimierung ist völlig optional.

Appendix F.5. Control Over Version Negotiation (Kontrolle über Versionsverhandlung)

Da BGP-4 in der Lage ist, aggregierte Routen zu tragen, die in BGP-3 nicht richtig dargestellt werden können, sollte (SHOULD) eine Implementierung, die BGP-4 und eine andere BGP-Version unterstützt, die Fähigkeit bieten, nur BGP-4 auf Pro-Peer-Basis zu sprechen.

Appendix F.6. Complex AS_PATH Aggregation (Komplexe AS_PATH-Aggregation)

Eine Implementierung, die sich dafür entscheidet, einen Pfad-Aggregationsalgorithmus bereitzustellen, der signifikante Mengen an Pfadinformationen beibehält, möchte möglicherweise das folgende Verfahren verwenden:

Zum Zweck der Aggregation von AS_PATH-Attributen zweier Routen modellieren wir jedes AS als Tupel <type, value>, wobei "type" einen Typ des Pfadsegments identifiziert, zu dem das AS gehört (z.B. AS_SEQUENCE, AS_SET), und "value" die AS-Nummer ist. Zwei ASe werden als gleich bezeichnet, wenn ihre entsprechenden <type, value>-Tupel gleich sind.

Der Algorithmus zum Aggregieren zweier AS_PATH-Attribute funktioniert wie folgt:

a) Identifizieren Sie dieselben ASe (wie oben definiert) innerhalb jedes AS_PATH-Attributs, die in beiden AS_PATH-Attributen in derselben relativen Reihenfolge sind. Zwei ASe, X und Y, werden als in derselben Reihenfolge befindlich bezeichnet, wenn entweder:

X Y in beiden AS_PATH-Attributen vorausgeht, oder
Y X in beiden AS_PATH-Attributen vorausgeht.

b) Das aggregierte AS_PATH-Attribut besteht aus ASen, die in (a) identifiziert wurden, in genau derselben Reihenfolge, wie sie in den zu aggregierenden AS_PATH-Attributen erscheinen. Wenn zwei aufeinanderfolgende in (a) identifizierte ASe nicht unmittelbar aufeinander folgen in beiden zu aggregierenden AS_PATH-Attributen, werden die dazwischenliegenden ASe (ASe, die zwischen den zwei aufeinanderfolgenden ASen sind, die gleich sind) in beiden Attributen in ein AS_SET-Pfadsegment kombiniert, das aus den dazwischenliegenden ASen beider AS_PATH-Attribute besteht. Dieses Segment wird dann zwischen die zwei aufeinanderfolgenden in (a) identifizierten ASe des aggregierten Attributs platziert. Wenn zwei aufeinanderfolgende in (a) identifizierte ASe unmittelbar aufeinander folgen in einem Attribut, aber nicht in einem anderen folgen, werden die dazwischenliegenden ASe des letzteren in ein AS_SET-Pfadsegment kombiniert. Dieses Segment wird dann zwischen die zwei aufeinanderfolgenden in (a) identifizierten ASe des aggregierten Attributs platziert.

c) Für jedes Paar benachbarter Tupel im aggregierten AS_PATH: Wenn beide Tupel denselben Typ haben, verschmelzen Sie sie zusammen, wenn dies nicht dazu führt, dass ein Segment einer Länge größer als 255 erzeugt wird.

Wenn als Ergebnis des obigen Verfahrens eine gegebene AS-Nummer mehr als einmal innerhalb des aggregierten AS_PATH-Attributs erscheint, sollten (SHOULD) alle bis auf die letzte Instanz (rechteste Vorkommen) dieser AS-Nummer aus dem aggregierten AS_PATH-Attribut entfernt werden.