Résumé

  • Un Internet-Draft individuel du 28 octobre propose six nouveaux types de paquets RTR et deux modes sur abonnement : événementiel et périodique.
  • Le nouveau Push Notify contient un identifiant d’abonnement, un type de changement et un numéro de série, mais aucune donnée RPKI modifiée. La livraison des données est décrite dans Periodic Update.

Le mot « push » a un prix : il faut que quelque chose d’utile arrive au routeur avant que le danger ait changé d’adresse. Le nouveau projet RTR promet une réaction rapide à une révocation ou à une autorisation ROA urgente. À lire ses formats de paquets, l’urgence reçoit une cloche ; les données attendent l’horaire.

La cloche existe déjà. Dans RFC 8210, le cache peut envoyer de lui-même un Serial Notify. Le routeur peut alors lancer immédiatement une Serial Query ou une Reset Query, sans attendre son prochain rafraîchissement. Le projet 8210bis actuel conserve cette répartition : le cache signale, le routeur décide de demander les modifications, la réponse transporte les annonces et retraits. Réduire ce circuit à un simple « modèle pull » efface sa première initiative.

Les auteurs proposent une souscription après la synchronisation initiale. Le routeur choisit les notifications déclenchées par un événement, les mises à jour périodiques, ou les deux. Il peut se désabonner. Six types de paquets supplémentaires sont demandés à l’IANA. Pour le cache, chaque abonné devient un état à gérer ; pour l’opérateur, la question est de savoir ce que cet état achète en secondes réellement gagnées.

Dans le mode événementiel, Push Notify indique un numéro de série et la catégorie de la modification, par exemple ROA, ASPA ou clé de routeur. Le dessin du paquet ne transporte aucun de ces objets. Le texte ne décrit pas non plus la séquence qui remettrait au routeur les données après cette nouvelle notification. Une alerte peut précéder le minuteur de rafraîchissement ; l’alerte seule ne met pas la table de validation à jour.

Le mode périodique fait autre chose. Periodic Update envoie, à l’intervalle accordé, Cache Response, des paquets de données éventuels, puis End of Data. Il annonce le numéro de série que le cache attribue au routeur. Si ce numéro ne correspond pas à son état réel, le routeur doit refuser les données. Cette vérification donne au destinataire un droit de veto précis sur une livraison non sollicitée.

Le Datatracker de l’IETF classe le texte comme projet individuel destiné à Standards Track, encore à I-D Exists. Il ne publie ni essai de déploiement ni comparaison reproductible des délais. Une version suivante qui détaille le transfert déclenché par l’événement et mesure le temps jusqu’à l’acceptation des données changerait le bilan. Pour l’instant, le mécanisme urgent décrit une notification, et le mécanisme porteur de données décrit une cadence.