Appendix F. Implementation Recommendations (Annexe F. Recommandations d'implémentation)
Appendix F. Implementation Recommendations (Annexe F. Recommandations d'implémentation)
Cette section présente quelques recommandations d'implémentation.
Appendix F.1. Multiple Networks Per Message (Multiples 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 multiples messages, mais la surcharge de balayage de la table de routage pour les mises à jour vers les pairs BGP et autres protocoles de routage (et l'envoi des messages associés) est également encourue plusieurs fois.
Appendix F.2. Reducing Route Flapping (Réduction du battement de routes)
Pour éviter un battement excessif des routes, un haut-parleur BGP qui doit retirer une destination et envoyer une mise à jour sur une route plus spécifique ou moins spécifique devrait 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 les ensembles d'attributs de différents messages de mise à jour qui sont sémantiquement identiques. Pour faciliter cela, il est utile comme optimisation d'ordonner les attributs de chemin selon le code de type. Cette optimisation est entièrement facultative.
Appendix F.4. AS_SET Sorting (Tri AS_SET)
Une autre optimisation utile qui peut être effectuée pour simplifier cette situation consiste à trier les numéros AS trouvés dans un AS_SET. Cette optimisation est entièrement facultative.
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 supporte BGP-4 et une autre version BGP devrait fournir la capacité de ne parler que BGP-4 sur une base par pair.
Appendix F.6. Complex AS_PATH Aggregation (Agrégation AS_PATH complexe)
Une implémentation qui choisit de fournir un algorithme d'agrégation de chemin conservant des quantités importantes 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, valeur>, où "type" identifie un type de segment de chemin auquel l'AS appartient (par exemple, AS_SEQUENCE, AS_SET), et "valeur" est le numéro AS. Deux AS sont considérés comme identiques si leurs tuples <type, valeur> correspondants sont identiques.
L'algorithme pour agréger deux attributs AS_PATH fonctionne comme suit :
a) Identifiez 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.
b) L'attribut AS_PATH agrégé consiste en AS identifiés dans (a), dans exactement le même ordre qu'ils apparaissent dans les attributs AS_PATH à agréger.
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 provoque 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 sauf la dernière instance (occurrence la plus à droite) de ce numéro AS devraient être supprimées de l'attribut AS_PATH agrégé.