Resumen

  • draft-geng-grow-bmp-monitor-options-00 define notificaciones Enable y Disable para declarar qué vistas RIB y estadísticas sigue observando un emisor BMP. La revisión 00 es un Internet-Draft individual y el tipo TBD2 aún no está asignado.
  • Un Disable de RIB obliga al colector a purgar la vista <Peer, AFI, SAFI> correspondiente. La autenticación mutua protege el transporte, pero no sustituye la autorización humana, la validación del alcance, el recibo de borrado ni una prueba de que la vista reactivada volvió a estar completa.

Una hora sin actualizaciones puede ser una buena noticia: nada cambió. También puede significar que el router dejó de exportar una familia de direcciones al colector. La sesión TCP y el indicador de BMP pueden seguir activos mientras la base conserva rutas antiguas con apariencia de actualidad.

BMP Extension for Monitoring Options (MO) Notification, fechado el 30 de septiembre de 2026, intenta dar nombre a esa diferencia. Es una revisión 00 individual con intención de Standards Track y caducidad el 3 de abril de 2027. No es un RFC, ni una decisión de grupo de trabajo, ni prueba de código desplegado. TBD2 es una solicitud de número, no una asignación de IANA.

El silencio no contiene su propia explicación

RFC 7854 permite exportar información estructurada sobre sesiones, rutas y estadísticas BGP. RFC 8671 incorporó Adj-RIB-Out y RFC 9069 la Local RIB. Aun así, el protocolo base no comunica dentro de la sesión que el operador cambió la configuración de monitorización.

El nuevo mensaje MO lo haría explícito. Para RIB, distingue Adj-RIB-In, Adj-RIB-Out y Loc-RIB; separa Pre-Policy de Post-Policy; incluye un bit Enable/Disable y una lista de pares AFI/SAFI. Puede llevar Per-Peer Header detrás del Common Header. Otro formato identifica tipos de estadísticas.

Cada dimensión delimita el impacto. “Monitorización desactivada” no basta para reconstruir una decisión. El registro necesita emisor, peer, superficie RIB, etapa de política, AFI, SAFI y hora.

El aviso es también una mutación destructiva

Cuando el operador desactiva la monitorización de una familia, el emisor debe enviar inmediatamente MO Disable. Al recibirlo, el colector debe purgar inmediatamente todas las entradas almacenadas que pertenecen a esa vista <Peer, AFI, SAFI>.

Eliminar la vista activa evita que datos sin observación sigan presentándose como actuales. Pero la operación deja de ser simple telemetría. Una orden que borra estado debe tratarse como un acto administrativo destructivo, aunque el campo se llame opción.

La diferencia importa para todo lo que consume BMP: mapas de topología, detección de fugas, comprobaciones de política y análisis forense. Una purga correcta los protege de rutas obsoletas. Una purga demasiado amplia los deja ciegos. En ambos casos, la sesión puede seguir figurando como sana.

El propio borrador advierte que mensajes MO no autorizados podrían engañar al colector para que purgue toda su base mediante falsos Disable. Por eso exige autenticación mutua y protección de transporte, por ejemplo TLS.

TLS demuestra la identidad del extremo de la sesión y la integridad del canal. No demuestra qué persona aprobó el cambio, si la automatización eligió el AFI/SAFI correcto o si un router autenticado está comprometido. Autenticar al mensajero no autoriza sin límite todas las eliminaciones que puede describir.

Higiene de la vista y custodia histórica

La obligación de purgar inmediatamente se refiere a las entradas RIB almacenadas como vista operativa. La revisión 00 no formula una política completa de conservación ni prohíbe mantener evidencia histórica separada.

El colector puede retirar al instante la vista no observada y conservar, bajo una regla local, un hash previo, una copia histórica o un asiento inmutable del cambio. Esa copia debe identificarse como historia, nunca servir en silencio como estado actual. Y un log que sólo diga “éxito” es insuficiente si no identifica la vista y cuántas entradas fueron alteradas.

Un recibo sólido vincula la solicitud aprobada con la sesión autenticada y los campos exactos del mensaje. Detalla qué se borró, qué se preservó y si la transacción terminó completa. Antes de mutar la base, el colector debe poder rechazar una petición mal formada o fuera del alcance autorizado al emisor.

Reactivar no equivale a reconstruir

Para reactivar la observación, el borrador propone enviar Enable y reanudar los mensajes Route Monitoring. El colector recompone la vista a medida que llegan.

Sin embargo, no hay marcador de inicio de instantánea, cantidad esperada, marcador final ni condición normativa de completitud. La primera ruta nueva sólo prueba que volvió la ingestión. No prueba que ya llegaron todas las rutas actuales ni que no hubo un hueco.

Una tabla parcialmente nueva puede engañar más que una vista claramente desactivada. Conviene distinguir disabled, rebuilding y current, y no devolver la confianza a los consumidores hasta cerrar una condición explícita.

Otro borrador individual, draft-geng-grow-bmp-rr-sync-00, propone por separado mensajes de BMP Route-Refresh con límites BoRR/EoRR. Esa propuesta confirma que sincronizar una imagen completa es un problema distinto. No forma parte de MO, tampoco es una norma aprobada y no puede darse por disponible.

La autoridad de borrado necesita una cadena de recibos

La prueba operativa debe conservar: revisión e implementación exactas; identidades mutuas; cambio aprobado; peer, tipo y subtipo RIB, AFI/SAFI; permiso del emisor para ese alcance; filas purgadas y preservadas; evidencia histórica; Enable equivalente; época de reconstrucción y condición de completitud; sólo después, la restauración de las decisiones aguas abajo.

Ningún eslabón prueba el siguiente. Un certificado válido no valida el alcance. Un Disable bien codificado no prueba autorización. Una purga correcta no garantiza que sobrevivió la evidencia. Enable no significa tabla completa.

La doctrina de Lu Heng separa bien las responsabilidades. La especificación inicial mínima puede fijar campos y transiciones deterministas para interoperar. Retención, aprobación, radio de impacto y umbral de confianza son decisiones locales de quien soporta el riesgo. La adopción voluntaria se demuestra con código en ejecución y recibos, no con la publicación del documento.

Cuando un mensaje de observación puede borrar lo observado, ya pertenece al plano de control de la evidencia.

Fuentes