Resumen

  • RFC 9736 separa los códigos TLV de Peer Up e Initiation y obliga a conservar el orden de String TLV repetidos. Aclara la propiedad de la extensión, no la conducta de una implementación desplegada.
  • Una afirmación operativa necesita recibos desde la versión del registro y los bytes serializados hasta el parser, el almacenamiento, la sesión, la ruta, el reenvío y el efecto observado.

Una colisión de propiedad, no de paquetes

Initiation describe al sistema monitorizado; Peer Up informa sobre una sesión BGP. RFC 7854 permitió que ambos usaran el mismo espacio de Information TLV. La decisión parecía económica, pero con nuevas extensiones volvió ambiguo quién podía asignar cada número y en qué contexto debía interpretarse.

RFC 9736 divide el libro contable. El registro existente pasa a llamarse BMP Initiation Information TLVs; nace BMP Peer Up Message TLVs. Initiation conserva String como Type 0, sysDescr como Type 1 y sysName como Type 2. Peer Up contiene String en Type 0, VRF/Table Name en Type 3 y Admin Label en Type 4. Los huecos correspondientes quedan reservados para impedir que vuelvan a confundirse los contextos.

El RFC también fija la forma. String es UTF-8 y termina por la longitud declarada, no por un carácter nulo. Information es opcional en Peer Up y su presencia se deduce de Message Length. String puede repetirse, pero el receptor debe mantener el orden al reportarlo. Un modelo de datos que convierta esa secuencia en un único valor habrá perdido evidencia sin violar necesariamente la apariencia de su panel.

Lo que no dice la compatibilidad

La afirmación de que las implementaciones conformes con RFC 7854, 8671 y 9069 también cumplen RFC 9736 explica la continuidad normativa de los códigos ya definidos. No identifica versiones reales de software ni verifica cómo trataron los datos.

Hay varios fallos plausibles. El parser puede quedarse con el último String repetido. Puede mostrar Type 3 como nombre de tabla pero asociarlo al peer Loc-RIB emulado equivocado. Puede descartar un tipo futuro desconocido sin contador ni registro bruto. En todos esos casos IANA sigue mostrando el registro correcto y la evidencia local sigue siendo insuficiente.

Por eso el recibo comienza antes del parser. Deben conservarse los bytes exactos, la sesión BMP, el build y la configuración del emisor, Message Length y la secuencia TLV. La captura debe quedar ligada al build del colector, su tabla de tipos, su validación de longitudes y su política de desconocidos. Después se comparan el ingreso bruto, el objeto decodificado y la fila persistida. Sin el original, no puede saberse si un campo faltaba en el cable o desapareció dentro de la plataforma.

Un Peer Up no completa el trayecto

RFC 7854 usa Peer Up para informar que una sesión BGP llegó a Established e incluye ambos OPEN y datos TCP. También exige enviar Peer Up para peers que ya estaban Established cuando se abre la sesión BMP. La llegada del registro, por tanto, no marca necesariamente el instante en que nació la sesión BGP.

RFC 8671 separa además el estado Peer Up/Down de la decisión de enviar Route Monitoring o Route Mirroring para Adj-RIB-In o Adj-RIB-Out. Initiation, Peer Up, el volcado inicial, End-of-RIB y las actualizaciones incrementales son pruebas distintas. La presencia de una no demuestra la integridad de las demás.

RFC 9069 añade peers emulados para Loc-RIB, a veces varios por tabla para familias de direcciones diferentes. VRF/Table Name aporta contexto, pero un nombre como global no es una identidad universal. También hacen falta el distinguidor, el BGP ID y las capacidades OPEN.

La cadena que sostiene una decisión

El operador debe poder señalar: la versión del registro, la versión del emisor, la sesión y época del peer, los bytes recibidos, la versión del parser, la política de tipos desconocidos, los recibos bruto y decodificado, la corroboración de sesión, la cobertura de rutas, la observación de RIB/FIB o prueba activa, la autorización de la acción y el resultado posterior.

La cadena puede detenerse. Peer Up puede probar un informe de sesión y dejar desconocida la aceptación de rutas. Un feed íntegro puede dejar desconocido el hardware. Una prueba de reenvío puede no medir el efecto empresarial. RFC 9736 hace fiable la propiedad del esquema; la disciplina operativa consiste en no venderla como prueba del resto.