Résumé

  • Le projet -13 reprend les valeurs d’administration d’une Route Target dans un autre sous-type d’Extended Community, sans lui donner d’effet sur la diffusion des routes ni sur l’import dans un VRF.
  • La copie transitive peut franchir une frontière d’AS, tandis qu’un filtre eBGP calé sur le sous-type de la Route Target peut ne pas la reconnaître.

Dans BGP, les étiquettes sont petites. Leurs effets, eux, ne le sont pas toujours.

Une Route Target (RT) peut indiquer à quel VPN rattacher une route. Dans les réseaux qui l’emploient, elle peut limiter les routeurs qui reçoivent cette route et déclencher son import dans un VRF configuré pour l’accepter. Une Extended Community ordinaire peut transporter une étiquette liée sans revendiquer ces pouvoirs. Cette différence compte lorsqu’une route doit être associée à un VPN sur une partie seulement de ses routeurs PE.

C’est le cas décrit par le projet -13, mis à jour le 28 octobre. Imaginons dix routeurs PE qui importent les routes VPN portant RT1. Une autre route doit être associée à ce VPN sur un sous-ensemble d’entre eux, mais sa distribution dépend d’une autre RT, RT3. Réutiliser RT1 comme étiquette d’association laisserait entendre que tous ses importateurs doivent recevoir la route. Créer une étiquette différente pour chaque sous-ensemble multiplierait les valeurs pour un seul VPN.

La réponse du projet est une Extended Community dérivée : conserver les valeurs Global Administrator et Local Administrator de la RT, remplacer le sous-type, puis nommer le résultat RT-derived EC. Les valeurs renvoient à la RT ; le sous-type indique que cette copie n’est pas elle-même une RT.

La distinction est nette. Selon ce projet, le RT-derived EC ne limite pas la propagation, n’importe pas la route dans un VRF et ne correspond pas à une règle qui recherche la RT d’origine. Il ne peut pas non plus être transporté dans le NLRI Route Target Membership défini par RFC 4684. Le projet fixe la correspondance et les codes. Un autre document doit dire ce que le récepteur en fait.

La difficulté apparaît à la frontière. Le projet conserve l’octet de poids fort du champ Type ; une communauté dérivée d’une RT transitive reste donc transitive. Sans politique contraire, elle peut franchir une frontière d’AS. Une règle conçue pour filtrer ou réécrire le sous-type RT ne couvrira pas automatiquement le sous-type dérivé. Même valeur d’administrateur et valeur locale ; autre code ; résultat de correspondance différent.

Le projet consigne l’attribution du sous-type 0x15 dans plusieurs registres Extended Community, notamment des formes transitives propres aux AS. Il ne l’attribue pas à tous les formats de RT possibles ; d’autres correspondances restent demandées ou provisoires. RFC 4360 explique pourquoi le champ Type structure les politiques sur les Extended Communities. Ici, c’est justement le sous-type qui peut faire rater à un filtre une valeur de la même famille.

Le 30 octobre, une revue de l’Operations Directorate de l’IETF a examiné la version 13 et demandé une section consacrée aux considérations opérationnelles. Gen Chen cite le filtrage inter-AS et le risque de fuite, les limites du mécanisme et le comportement des anciens BGP ; il suggère de filtrer le sous-type 0x15 aux frontières eBGP lorsqu’on ne veut pas le propager. C’est une remarque de revue, pas la preuve d’une fuite. Elle pointe l’écart entre définir une valeur et expliquer son parcours dans un réseau hétérogène.

Au 2 novembre, le projet est en évaluation par l’IESG, avec une discussion prévue le 5 novembre. Un document informatif peut fixer la correspondance des bits sans décider qui doit les filtrer, ce que feront les anciens routeurs ni comment contenir chaque usage ultérieur. Le sous-type tient dans un octet ; l’inventaire des politiques, lui, prend bien plus de place.

Sources : projet -13 · revue Operations Directorate · RFC 4360 · RFC 4684