Mon blog

Le protocole MPLS de commutation de paquets selon une étiquette (label) utilise souvent LDP comme mécanisme d'attribution des étiquettes. LDP ne fonctionnait bien qu'à l'intérieur d'une même zone du système autonome et ce nouveau RFC étend LDP pour le cas où on dispose de plusieurs zones.

La section 1 du RFC explique la motivation pour cette modification : un certain nombre d'opérateurs ont tiré profit du caractère hiérarchique de protocoles de routage internes comme OSPF ou IS-IS pour créer plusieurs zones (areas) dans leur système autonome. Ce découpage en zones (section 3 du RFC 2328) permet de gérer des très grands systèmes autonomes, en évitant que chaque routeur connaisse tout le réseau.

Mais, sur les réseaux MPLS utilisant LDP, pour qu'un routeur qui reçoit une correspondance entre une étiquette MPLS et une FEC (Forwarding Equivalent Class, section 2.1 du RFC 3031) la prenne en compte, la norme LDP (section 3.5.7.1 du RFC 5036) impose que la table de routage du routeur possède une entrée qui corresponde exactement cette FEC. Par exemple pour monter un tunnel MPLS, le routeur MPLS doit avoir dans sa table une route avec une correspondance exacte avec le point de sortie du tunnel, c'est-à-dire en IPv4 le préfixe en /32 ; avoir une route en /24 qui couvrirait ce /32 ne suffit pas.

En pratique, sur les réseaux MPLS utilisant LDP et qui ont un IGP multi-zones, monter des tunnels vers ou depuis des routeurs appartenant à d'autres zones nécessitait donc des bricolages comme l'annonce des adresses (préfixes en /32 ou bien /128 en IPv6) dans tous les sens entre tout plein de zones en passant aussi par la zone qui sert d'épine dorsale, ce qui est très lourd à gérer et rend l'intérêt des zones douteux. Elles avaient justement été conçues pour éviter de transporter des détails internes à une zone, en agrégeant les annonces de préfixes...

La section 4 du RFC détaille le problème, notamment dans le cas de tunnels (RFC 4364, RFC 4761 et RFC 4762). La section 6 fournit des exemples, avec de jolis dessins.

La section 5 présente la solution. Notre RFC 5283 permet donc désormais de faire accepter à LDP des associations étiquette/FEC pour lesquelles le LSR (le routeur MPLS) aurait des routes moins spécifiques, par exemple parce qu'elles ont été agrégées. C'est donc simplement l'application de la traditionnelle règle IP de la « meilleure correspondance » (longest match) à la sélection d'une étiquette MPLS.

L'ancienne règle continue à s'appliquer par défaut (le RFC impose que la nouvelle extension ne soit pas activée automatiquement). En effet, si on arrête de publier les préfixes les plus spécifiques, il faut que tous les routeurs MPLS de la zone acceptent l'extension. Elle est donc déployable de manière progressive (section 7.1) mais à condition de faire attention.

Merci à Sarah Tharan pour ses explications détaillées sur cette extension.