Résumé

  • Le RFC 9003 permet un texte UTF-8 libre de 255 octets au plus avec les seuls sous-codes Administrative Shutdown et Administrative Reset. Il remplace le plafond de 128 octets du RFC 8203.
  • La NOTIFICATION ferme aussitôt la connexion. BGP ne confirme ni la réception ni la bonne compréhension ; sans protection du transport, le texte peut être falsifié ou lu.
  • Le motif, le déplacement préalable du trafic et la conservation des routes sont indépendants. La preuve va des octets émis au journal reçu, puis au FSM, au RIB, au FIB et aux paquets.

Un changement approuvé débute à 02 h 00. Le routeur envoie un Cease portant [CHG-4281] mise à niveau de l’edge ; retour prévu dans 30 minutes, puis ferme TCP. Le NOC distant sait immédiatement que la rupture semble volontaire. Il ne sait pas encore si l’auteur était habilité, si les paquets ont quitté le lien, si des routes obsolètes restent actives ou si le délai annoncé vaut engagement.

Un espace de parole strictement borné

Le RFC 4486 classe plusieurs causes de Cease. Le RFC 9003 n’ouvre son champ libre qu’aux sous-codes 2 et 4. Une limite de préfixes, un peer supprimé, une collision ou un manque de ressources gardent leur catégorie. Un texte séduisant ne corrige pas un sous-code mensonger.

Le format est volontairement modeste : un octet de longueur, puis autant d’octets UTF-8 ; zéro signifie aucun texte. Le champ n’est pas terminé par NUL et la forme UTF-8 la plus courte est obligatoire. Le maximum porte sur les octets, non sur les caractères. Une phrase russe, arabe, chinoise ou japonaise consomme plus vite le budget, raison pratique pour laquelle le RFC 9003 a rendu obsolète le RFC 8203.

Le seuil historique reste utile. Lorsque le support actuel du voisin est établi, 255 octets sont permis. Lorsqu’il est inconnu, le message devrait rester à 128 octets ou moins. Un ancien speaker peut signaler les données supplémentaires comme erreur tout en traitant normalement la NOTIFICATION terminale.

Cette architecture correspond à une spécification initiale minimale. Le protocole partage deux sous-codes, une longueur et un encodage ; il ne centralise ni tickets, ni langue, ni droit de divulgation, ni rétention. Les organisations conservent leurs décisions futures.

Une déclaration sans accusé de réception

Selon le RFC 4271, l’envoi d’une NOTIFICATION entraîne la fermeture immédiate. Le destinataire ne peut donc pas répondre par une seconde NOTIFICATION si le premier message est erroné. Le RFC 9003 en tire une limite nette : aucune confirmation de réception et de compréhension correcte n’existe.

Le journal de l’émetteur prouve une tentative locale. Une capture prouve les octets expédiés. Le journal du voisin prouve leur arrivée et leur décodage. Aucun de ces éléments ne prouve qu’un humain a lu la phrase, retrouvé le ticket ou accepté son calendrier.

Le numéro partagé doit pointer vers un canal hors bande authentifié. C’est plus sûr qu’un récit interne copié sur le fil, et plus utile qu’une référence inconnue de l’autre partie. Le BGP terminal fournit l’index au moment critique ; la conversation, l’approbation et la correction restent ailleurs.

Un UTF-8 valide peut raconter une fausse histoire

La validation syntaxique protège le parseur, pas la vérité. Un texte parfaitement valide peut contenir un faux ticket, des caractères Unicode confusables ou une mise en forme destinée à ressembler à une nouvelle ligne syslog. La forme la plus courte bloque des encodages interdits ; elle ne garantit ni identité ni honnêteté.

Le récepteur doit stocker la valeur brute séparément de son rendu sûr, neutraliser les caractères de contrôle et distinguer visuellement le texte du peer des champs locaux. La limite de 255 octets borne l’exposition ; elle n’assainit pas son contenu.

Sans intégrité du transport, un adversaire peut forger le message ; sans confidentialité, il peut l’observer. Les numéros de ticket, noms, hôtes, clients et hypothèses d’incident deviennent alors des données exposées. La minimisation recommande une clé commune, une classe de changement et une fenêtre, jamais des identifiants personnels, secrets ou détails inutiles.

Même un transport authentifié ne signe pas l’humain ni la véracité de sa phrase. Le récepteur traite donc le message comme une assertion non vérifiée jusqu’à corrélation avec un avis autorisé.

Expliquer n’est pas drainer

Le RFC 8326 agit avant la rupture : il déprécie les chemins, attend la convergence et ferme ensuite. Le RFC 9003 parle dans l’acte de fermeture. Il ne crée aucune alternative, ne modifie pas LOCAL_PREF et ne déplace aucun paquet dans le passé.

Les deux mécanismes peuvent se compléter : drainage mesuré, puis fermeture expliquée. Ils doivent garder deux preuves. Une raison élégante ne garantit pas une maintenance sans perte.

Le RFC 8538 ajoute encore une dimension. Lorsque les deux peers échangent le bit N de Graceful Notification, une NOTIFICATION autre que Hard Reset peut conserver des routes comme stale. Le sous-code 9 demande au contraire une réinitialisation complète. Le RFC suggère Hard Reset pour Administrative Shutdown et laisse Administrative Reset au contrôle de l’utilisateur, sans imposer une correspondance absolue.

Si un message administratif voyage dans un Hard Reset, le sous-code externe vaut Hard Reset et la NOTIFICATION administrative, texte compris, se trouve encapsulée. Une supervision qui ne montre que l’enveloppe perd la raison. Inversement, conserver une route stale ne prouve pas que son next hop fonctionne encore.

L’autre réseau garde son autonomie

L’émetteur décide de fermer et de parler. Le récepteur décide de croire, journaliser, masquer, alerter, réessayer et conserver des routes. Le RFC 4486 conseille de freiner les reconnexions après certaines causes longues, notamment Administrative Shutdown, puis de demander une intervention. Le texte retour dans 30 minutes ne programme pas à distance ce minuteur.

L’automatisation locale doit partir du sous-code et de sa propre politique authentifiée. Un ticket connu enrichit l’incident ; un ticket inconnu déclenche une vérification. Un délai guide l’opérateur, pas une commande exécutable.

Une mauvaise classification peut être plus dangereuse qu’une phrase absente. Décrire une suppression permanente comme Reset entretient une boucle de connexion ; appeler Shutdown une interruption brève peut retarder le retour. Le système structuré et le texte doivent être comparés.

La preuve traverse sept surfaces

Avant le test, définir l’autorité de rédaction, le vocabulaire, l’espace de tickets, les données interdites et le plafond compatible. Préparer des canaris ASCII et multioctets de taille exacte, à 128 puis 255 seulement quand le support est prouvé.

Sur le fil, enregistrer endpoints, heure, code, sous-code, longueur, octets, décodage et éventuelle encapsulation Hard Reset. À la réception, vérifier rendu, échappement, syslog, télémétrie, corrélation, rétention et redaction.

Puis mesurer la fermeture : socket, FSM, tentatives, N-bit, withdrawals ou stale, minuteur, RIB et FIB. Enfin observer trafic, pertes et reprise. C’est seulement alors que l’on sait si l’événement a été expliqué et correctement exécuté.

Le retour arrière peut supprimer le texte libre, revenir à 128 octets, imposer un vocabulaire ou ne conserver que la clé du ticket. Il ne doit ni masquer le vrai sous-code ni détruire l’avis hors bande.

Le mérite du RFC 9003 est sa modestie : une session qui disparaît peut laisser un indice commun. L’indice devient preuve grâce à l’autorisation locale, la divulgation minimale, la corroboration et le réseau observé. Expliquer sa fermeture n’a jamais signifié imposer son interprétation.