Résumé

  • RFC 1136 appelait domaine administratif l’espace où une organisation maintient un plan technique cohérent et un niveau déterminé de confiance ; un domaine de routage est, plus étroitement, l’ensemble qui applique une même procédure de calcul.
  • Un domaine administratif peut contenir plusieurs domaines de routage, mais un domaine de routage ne peut pas traverser plusieurs domaines administratifs. Cette règle décrit une discipline d’ingénierie, non un droit de propriété ni un itinéraire observé.

Le même contour ne répondait pas à toutes les questions

Le vocabulaire de l’Internet naissant comprimait facilement plusieurs réalités dans « autonomous system ». RFC 827 avait utilement protégé la liberté interne : le protocole de routage entre passerelles d’un système restait une affaire privée. Mais lorsque les réseaux sont devenus nombreux et que le cœur unique a cessé d’être une description convenable, le même mot risquait de désigner à la fois une méthode, un interlocuteur extérieur, un groupe de politique et une identité institutionnelle.

RFC 1136, document informationnel de Susan Hares et Dave Katz, ne prétendait pas imposer une norme. Il proposait plutôt un instrument de lecture tiré du cadre OSI. L’important n’était pas de remplacer une étiquette par deux acronymes. Il s’agissait d’empêcher qu’un dessin de connectivité fasse croire qu’il répond déjà aux questions de confiance, de décision et de calcul.

Un domaine administratif, ou AD, réunit des systèmes et sous-réseaux exploités par une organisation ou une autorité administrative. Les composants internes sont supposés coopérer avec une confiance significative ; l’information provenant d’un autre AD est moins digne de confiance. Pour le routage extérieur, l’AD peut être vu comme un ensemble cohérent dont l’intérieur importe peu. Cette abstraction économise des détails. Elle ne fait pas de l’intérieur un bien commun, ni du voisin un administrateur, ni d’un numéro une preuve d’identité juridique.

La hiérarchie que le RFC envisageait est elle-même limitée : elle reflète disponibilité et caractère autoritatif de l’information de routage, mais n’implique ni containment administratif ni arbre strict. Une position sur une carte d’information ne devient pas une chaîne de commandement.

Une procédure commune, pas une fiction d’uniformité

Le domaine de routage, RD, est défini plus rigoureusement. Ses systèmes emploient les mêmes métriques, des techniques compatibles pour les mesurer, le même protocole de diffusion d’information et le même algorithme de calcul de chemin. Dans ce périmètre, les systèmes peuvent déterminer l’atteignabilité d’un système terminal et dériver un chemin. RFC 1136 rapproche ce protocole interne d’un IGP.

Cette capacité est technique. Elle ne démontre pas que toute route choisie est autorisée, que chaque participant possède les mêmes actifs, ou que la confiance est sans limite. Elle dit seulement quelle procédure permet de former une connaissance de routage dans un ensemble délimité. Les sous-domaines montrent pourquoi : on peut cacher largement les détails topologiques d’une partie à une autre afin de réduire le volume d’information distribué. Ce qui est caché cesse d’être nécessaire au calcul extérieur ; il ne cesse ni d’exister ni d’exiger une gouvernance propre.

Le modèle accepte donc plusieurs RDs dans un AD. Les interactions peuvent être étroitement couplées, y compris entre procédures différentes, ou davantage fondées sur une politique. Ce qui les tient ensemble n’est pas une parfaite uniformité, mais une coordination serrée et un plan technique unifié. À l’inverse, le RFC interdit qu’un même RD s’étende sur plusieurs ADs. Si le contrôle de politique se sépare, il faut réexaminer le périmètre de la procédure commune au lieu de conserver l’unité seulement parce qu’elle est commode sur le papier.

La frontière extérieure gardait les accords explicites

Entre ADs, le problème changeait de nature. RFC 1136 parlait d’un flux d’information structuré entre organisations qui peuvent avoir besoin d’accords multilatéraux formels. Les contraintes juridiques, politiques, de sécurité et d’accès peuvent compter. Surtout, des accords multiples ne sont vraisemblablement pas transitifs de manière implicite. Le fait que A échange avec B et B avec C ne donne pas silencieusement à A le même droit ou la même obligation envers C.

L’exemple du RFC est concret. Un réseau relié à un régional NSFNET ajoute une connexion à ESNET. Administrateurs locaux et régionaux doivent coordonner le changement, peut-être modifier les limites de politique et de routage ; autrement, des boucles ou violations de politique peuvent surgir. Le nouveau lien n’est pas le problème en soi. Il change les hypothèses sur le transport, l’information reçue et l’export, et ces hypothèses doivent être décidées là où elles s’exécutent.

Le document observait aussi qu’un numéro d’AS pouvait fonctionner comme abstraction de regroupement de politique et, dans cette lecture, comme numéro d’AD. Cette représentation extérieure n’était pas un certificat d’homogénéité : un régional pouvait contenir plusieurs RDs. Un identifiant rend une surface adressable ; il ne fournit pas, à lui seul, la preuve du plan commun, du consentement, de la propriété ou de la compétence opérationnelle.

RFC 1136 n’est pas une constitution actuelle du routage. Sa leçon historique est plus modeste : une frontière utile doit dire quelle coordination elle supporte réellement. Une adjacency ne devient pas un mandat. Un IGP partagé ne devient pas un titre. Une vue extérieure ne devient pas l’ensemble de la topologie ni de l’autorité qui l’organise.

Sources