Appendix F. Implementation Recommendations (Recommandations d'implémentation)

Cette section présente quelques recommandations d'implémentation.

Appendix F.1. Multiple Networks Per Message (Plusieurs réseaux par message)

Le protocole BGP permet de spécifier plusieurs préfixes d'adresse avec les mêmes attributs de chemin dans un seul message. L'utilisation de cette capacité est fortement recommandée. Avec un préfixe d'adresse par message, il y a une augmentation substantielle de la surcharge chez le récepteur. Non seulement la surcharge système augmente en raison de la réception de plusieurs messages, mais la surcharge du balayage de la table de routage pour les mises à jour vers les pairs BGP et d'autres protocoles de routage (et l'envoi des messages associés) est également encourue plusieurs fois.

Une méthode de construction de messages contenant de nombreux préfixes d'adresse par ensemble d'attributs de chemin à partir d'une table de routage qui n'est pas organisée sur une base par ensemble d'attributs de chemin consiste à construire de nombreux messages au fur et à mesure que la table de routage est balayée. Au fur et à mesure que chaque préfixe d'adresse est traité, un message pour l'ensemble d'attributs de chemin associé est alloué, s'il n'existe pas, et le nouveau préfixe d'adresse y est ajouté. Si un tel message existe, le nouveau préfixe d'adresse y est ajouté. Si le message manque d'espace pour contenir le nouveau préfixe d'adresse, il est transmis, un nouveau message est alloué et le nouveau préfixe d'adresse est inséré dans le nouveau message. Lorsque toute la table de routage a été balayée, tous les messages alloués sont envoyés et leurs ressources sont libérées. Une compression maximale est obtenue lorsque toutes les destinations couvertes par les préfixes d'adresse partagent un ensemble commun d'attributs de chemin, ce qui permet d'envoyer de nombreux préfixes d'adresse dans un seul message de 4096 octets.

Lors de l'appairage avec une implémentation BGP qui ne compresse pas plusieurs préfixes d'adresse en un seul message, il peut être nécessaire de prendre des mesures pour réduire la surcharge du flot de données reçues lorsqu'un pair est acquis ou lorsqu'un changement significatif de topologie réseau se produit. Une méthode pour ce faire est de limiter le taux de mises à jour. Cela éliminera le balayage redondant de la table de routage pour fournir des mises à jour flash pour les pairs BGP et d'autres protocoles de routage. Un inconvénient de cette approche est qu'elle augmente la latence de propagation des informations de routage. En choisissant un intervalle de mise à jour flash minimum qui n'est pas beaucoup plus grand que le temps nécessaire pour traiter les plusieurs messages, cette latence devrait être minimisée. Une meilleure méthode serait de lire tous les messages reçus avant d'envoyer des mises à jour.

Appendix F.2. Reducing Route Flapping (Réduction du flapping de route)

Pour éviter un flapping de route excessif, un haut-parleur BGP qui doit retirer une destination et envoyer une mise à jour concernant une route plus spécifique ou moins spécifique devrait (SHOULD) les combiner dans le même message UPDATE.

Appendix F.3. Path Attribute Ordering (Ordre des attributs de chemin)

Les implémentations qui combinent des messages de mise à jour (comme décrit ci-dessus dans la Section 6.1) peuvent préférer voir tous les attributs de chemin présentés dans un ordre connu. Cela leur permet d'identifier rapidement des ensembles d'attributs provenant de différents messages de mise à jour qui sont sémantiquement identiques. Pour faciliter cela, il est utile d'optimiser en ordonnant les attributs de chemin selon le code de type. Cette optimisation est entièrement optionnelle.

Appendix F.4. AS_SET Sorting (Tri AS_SET)

Une autre optimisation utile qui peut être effectuée pour simplifier cette situation est de trier les numéros AS trouvés dans un AS_SET. Cette optimisation est entièrement optionnelle.

Appendix F.5. Control Over Version Negotiation (Contrôle de la négociation de version)

Parce que BGP-4 est capable de transporter des routes agrégées qui ne peuvent pas être correctement représentées dans BGP-3, une implémentation qui prend en charge BGP-4 et une autre version BGP devrait (SHOULD) fournir la capacité de ne parler que BGP-4 par pair.

Appendix F.6. Complex AS_PATH Aggregation (Agrégation complexe AS_PATH)

Une implémentation qui choisit de fournir un algorithme d'agrégation de chemin conservant des quantités significatives d'informations de chemin peut souhaiter utiliser la procédure suivante:

Pour les besoins de l'agrégation des attributs AS_PATH de deux routes, nous modélisons chaque AS comme un tuple <type, value>, où "type" identifie un type du segment de chemin auquel l'AS appartient (par exemple, AS_SEQUENCE, AS_SET), et "value" est le numéro AS. Deux AS sont dits identiques si leurs tuples <type, value> correspondants sont identiques.

L'algorithme pour agréger deux attributs AS_PATH fonctionne comme suit:

a) Identifier les mêmes AS (comme défini ci-dessus) dans chaque attribut AS_PATH qui sont dans le même ordre relatif dans les deux attributs AS_PATH. Deux AS, X et Y, sont dits être dans le même ordre si:

X précède Y dans les deux attributs AS_PATH, ou
Y précède X dans les deux attributs AS_PATH.

b) L'attribut AS_PATH agrégé se compose des AS identifiés en (a), dans exactement le même ordre qu'ils apparaissent dans les attributs AS_PATH à agréger. Si deux AS consécutifs identifiés en (a) ne se suivent pas immédiatement dans les deux attributs AS_PATH à agréger, alors les AS intervenants (AS qui sont entre les deux AS consécutifs qui sont identiques) dans les deux attributs sont combinés en un segment de chemin AS_SET qui se compose des AS intervenants des deux attributs AS_PATH. Ce segment est ensuite placé entre les deux AS consécutifs identifiés en (a) de l'attribut agrégé. Si deux AS consécutifs identifiés en (a) se suivent immédiatement dans un attribut, mais ne se suivent pas dans un autre, alors les AS intervenants de ce dernier sont combinés en un segment de chemin AS_SET. Ce segment est ensuite placé entre les deux AS consécutifs identifiés en (a) de l'attribut agrégé.

c) Pour chaque paire de tuples adjacents dans l'AS_PATH agrégé, si les deux tuples ont le même type, les fusionner ensemble si cela ne provoquera pas la génération d'un segment d'une longueur supérieure à 255.

Si, à la suite de la procédure ci-dessus, un numéro AS donné apparaît plus d'une fois dans l'attribut AS_PATH agrégé, toutes les instances sauf la dernière (occurrence la plus à droite) de ce numéro AS devraient (SHOULD) être supprimées de l'attribut AS_PATH agrégé.