Résumé

  • La RFC 2439 a fait de l’instabilité un état local : les retraits augmentaient l’indicateur de mérite d’une route, sa décroissance exponentielle le faisait baisser, et deux seuils distincts déterminaient sa suppression puis sa réutilisation.
  • L’expérience a montré ensuite que cette mémoire pouvait pénaliser un préfixe bien connecté pendant une convergence normale. La RFC 7196 n’a pas aboli le damping : elle a recommandé des seuils plus prudents et un mode facultatif qui calcule sans supprimer.

Le passé d’une route est devenu une donnée du présent

Dans les années 1990, les mises à jour BGP ne décrivaient pas seulement les destinations accessibles. Leur volume consommait aussi du temps processeur sur le routeur récepteur et chez les pairs qui recevaient les annonces retransmises. La RFC 2439 a proposé de réduire les changements répétés tout en cherchant à ne pas ralentir la convergence des routes relativement stables. Ce document Standards Track rapporte que des implémentations commerciales et des déploiements existaient déjà au moment de sa publication, en 1998. C’est un témoignage sur cette époque, pas une affirmation sur la configuration actuelle. RFC 2439 Notice RFC Editor

L’idée décisive consistait à mémoriser davantage que le dernier UPDATE. Un routeur recevant une route d’un pair externe pouvait maintenir un indicateur de mérite pour une identité de route. Chaque transition de l’état joignable à non joignable ajoutait une pénalité ; si la route restait stable, une décroissance exponentielle réduisait la valeur accumulée. Ce score ne diagnostiquait ni un câble en panne ni un pair malhonnête. Il décrivait les changements récemment observés par un routeur et influençait sa décision d’utiliser ou d’annoncer le chemin. RFC 2439

La joignabilité rétablie ne rendait donc pas immédiatement la route réutilisable. Le seuil de coupure, ou de suppression, décidait quand la retenir. Un seuil inférieur de réutilisation indiquait quand un chemin suspendu pouvait revenir dans la sélection. Un temps maximal de blocage limitait la durée de la suppression. Joignabilité, pénalité cumulée, état de suppression et sélection du meilleur chemin étaient liés, mais ne décrivaient pas le même fait. Un pair pouvait annoncer à nouveau sa route tandis que le routeur récepteur continuait à la supprimer. RFC 2439

Une mémoire, pas un simple délai universel

La RFC 2439 décrivait deux façons de limiter les annonces. Un minuteur fixe — associé ensuite au Minimum Route Advertisement Interval — cadencait les mises à jour. La méthode fondée sur la stabilité dépendait, elle, de l’historique des changements. Tant que le score restait sous le seuil de coupure, la route pouvait être utilisée ; une fois supprimée, elle demeurait inutilisable jusqu’à ce que sa valeur décroissante passe sous le seuil de réutilisation. Le damping dépendait donc de l’instabilité passée, et non d’un délai identique après chaque changement. RFC 2439 BGP-4

Les paramètres produisaient des effets distincts. La demi-vie fixait la vitesse de baisse du score quand la route était joignable ; l’implémentation pouvait retenir une autre décroissance, voire aucune, lorsqu’elle ne l’était pas. Un seuil de coupure plus élevé tolèrait davantage de changements avant la suppression. Un seuil de réutilisation plus bas exigeait plus de stabilité avant le rétablissement. L’exemple de la RFC 2439 montre pourquoi ces valeurs ne se résument pas à un minuteur universel : dans un scénario donné, deux ou trois retraits suffisaient à supprimer une route, qui devait ensuite rester annoncée et stable pendant environ une fois et demie à deux fois et demie la demi-vie avant réutilisation. Ce résultat dépend de paramètres précis ; ce n’est pas le délai garanti de tout routeur. RFC 2439

Le document délimitait aussi les endroits où appliquer le mécanisme. La RFC 2439 le destinait aux mises à jour reçues de pairs externes et avertissait qu’une suppression appliquée aux routes apprises en iBGP ou après sélection pouvait créer des boucles. Elle proposait d’identifier la route au minimum par le NLRI et, par défaut, par le chemin AS. Une pénalité attachée au seul préfixe ne raconte pas la même histoire qu’une pénalité attachée à un chemin précis vers cette destination. RFC 2439

Les détails d’implémentation déterminaient qui supportait le coût

En 2006, la revue opérationnelle RFC 4277 rapportait que les implémentations alors examinées ne conservaient pas l’historique par NLRI ou chemin AS unique, contrairement à l’exigence de RFC 2439. Dans un réseau densément maillé, indiquait-elle, cette différence pouvait supprimer une destination trop agressivement, parfois après une seule panne ; la revue disait avoir observé ces effets. Il s’agit d’un constat limité à ce rapport, pas d’une preuve que tous les routeurs se comportaient ainsi. Le document distinguait également le damping d’une session BGP, destiné aux erreurs persistantes du pair, du damping de routes individuelles. RFC 4277 RFC 2439

En 2014, la RFC 7196 décrivait un autre coût : un réseau riche en chemins peut générer davantage d’UPDATE pendant une convergence normale, et ainsi pénaliser un site bien connecté. Ses mesures citées trouvaient moins de préfixes supprimés lorsque le seuil était relevé, tout en conservant une partie de la baisse du trafic de mises à jour. L’étude rapportait une baisse de 19 % du taux d’UPDATE avec un seuil de 6 000 par rapport à l’absence de damping, et 90 % de préfixes supprimés en moins qu’avec 2 000 ; avec 12 000, elle indiquait que 0,22 % des préfixes étaient supprimés et que le taux horaire moyen baissait de 11 %. Ces chiffres décrivent l’étude d’une semaine citée dans la RFC, pas une prévision universelle. RFC 7196

La RFC 7196 recommandait au moins 6 000 pour un damping moins destructeur mais encore relativement agressif, et 12 000 pour une approche prudente. En parallèle, elle disait que les implémentations ne devraient pas modifier les paramètres configurables par défaut existants afin de préserver les configurations opérationnelles. Elle permettait aussi un mode de test qui calcule les routes qui auraient été supprimées sans les bloquer réellement. La réponse de 2014 était donc de mesurer et de recalibrer, non d’affirmer que le damping était toujours néfaste ou qu’un réglage convenait à toutes les topologies. RFC 7196

L’évolution historique n’est pas un simple passage de « damping activé » à « damping désactivé ». La RFC 2439 voulait contenir le churn en faisant peser le passé d’une route sur sa réutilisation immédiate. La RFC 4277 a montré que l’identité retenue par l’implémentation pouvait élargir la pénalité. La RFC 7196 a ensuite traité la convergence ordinaire et la bonne connectivité comme des coûts à mesurer avant d’appliquer la suppression. Le mécanisme pouvait réduire les mises à jour répétées, mais aussi retarder un chemin rétabli. Aucun de ces textes ne transforme un score de damping en preuve de défaillance physique, de mauvaise origine ou de panne universelle. RFC 2439 RFC 4277 RFC 7196 Scalable Routing Design Principles Notice Datatracker RFC 2439

Sources