John Scudder

Une connexion TCP peut être parfaitement établie sans que deux routeurs soient prêts à fournir le service BGP attendu. L'un connaît une extension que l'autre ignore; tous deux l'implémentent peut-être, mais un seul la déclare dans OPEN. Les RFC auxquelles le nom de John Scudder est attaché transforment cette incertitude en preuve bilatérale: une capacité optionnelle n'est utilisable que si les deux pairs l'annoncent, l'inconnu n'est pas fatal, et l'absence d'une fonction indispensable peut devenir un refus explicite plutôt qu'une compatibilité de façade.

Le dossier public de John Scudder relie l’exploitation des premiers réseaux dorsaux, la mise en œuvre de BGP, la validation de l’origine des routes, le traitement borné des erreurs et l’observation de l’état de routage. Sa portée ne tient pas au récit d’un inventeur isolé, mais à une question plus concrète : comment rendre les affirmations échangées par des systèmes autonomes comparables, les défaillances moins contagieuses et les changements suffisamment visibles pour qu’un opérateur puisse les expliquer puis les réparer.

Une session BGP transporte un ensemble de routes, pas un message isolé. Si un seul attribut est mal formé, fermer la session élimine certes l’information fautive, mais retire aussi les routes valides qui partageaient la même relation. Le travail auquel John Scudder a contribué pose une question plus exigeante : jusqu’où faut-il étendre la panne lorsque le récepteur comprend encore une partie du message ?