Resumen
draft-ietf-idr-bgp-rpki-yang-02expone medidores de validación de origen en cinco superficies BGP. La ruta YANG, el vecino y la familia de direcciones son parte de la observación.- Dos medidores pueden mostrar el mismo valor y representar rutas distintas. Validar tampoco demuestra selección, exportación, aceptación por el vecino ni reenvío real.
Antes del cambio había 10.000 rutas con origen válido. Después también. Si el objetivo fuera conservar un número, el trabajo habría terminado.
El objetivo real era conservar ciertos destinos por ciertos vecinos. Una ruta crítica pudo salir y otra irrelevante ocupar su lugar. La cantidad no se movió; la exposición operativa sí.
Ese es el problema que permite ver draft-ietf-idr-bgp-rpki-yang-02, fechado el 30 de septiembre de 2026. El borrador del grupo IDR define modelos YANG para validación del AS de origen, BGPsec y ASPA. En el modelo de origen coloca cuatro medidores—no verificado, desconocido, inválido y válido—en cinco lugares del procesamiento BGP.
Cada superficie formula una pregunta diferente
Las estadísticas aparecen en adj-rib-in-pre, adj-rib-in-post, loc-rib, adj-rib-out-pre y adj-rib-out-post, tanto para IPv4 como para IPv6.
La primera superficie muestra lo recibido antes de la política de entrada. La segunda, lo que queda después. El RIB local representa la vista seleccionada por el router. Las dos superficies de salida delimitan el tratamiento destinado a un vecino antes y después de su política.
Por eso, veinte rutas inválidas recibidas no implican veinte rutas inválidas admitidas. Diez mil rutas válidas en el RIB local no implican que se anunciaran a un vecino concreto. Diez mil después de la política de salida no demuestran que el vecino las aceptó. Ningún medidor demuestra por sí solo el recorrido de los paquetes.
Quitar la ruta YANG del panel quita el límite de la afirmación. También importan el vecino y el AFI/SAFI. Al sumar pares se puede ocultar la pérdida de un proveedor con una ganancia equivalente de otro; la cifra global queda estable mientras cambian el dominio de fallo, el coste y la geografía.
Contar miembros no identifica miembros
Un gauge32 expresa una cantidad actual. No lleva la lista ni una huella de las rutas que la forman.
Dos conjuntos pueden tener el mismo tamaño y miembros distintos. Una ruta sale y otra entra; la gráfica no se inmuta. Una política sustituye una clase de prefijos por otra; el total puede seguir idéntico. El medidor sigue siendo correcto. Lo incorrecto es traducir “misma cantidad” por “mismo estado”.
Cuando se necesita probar continuidad, hace falta un recibo de pertenencia. Puede ser una huella canónica de prefijo, origen, AS_PATH y siguiente salto, una lista acotada o pruebas explícitas para prefijos protegidos. La tecnología varía; la obligación no: el sistema debe poder contestar qué rutas contó.
También hay que registrar el tiempo. El borrador congelado no promete que lecturas de cinco rutas YANG formen una instantánea transaccional. Durante la convergencia, comparar una entrada tomada segundos antes que una salida puede inventar o borrar diferencias.
«Válido» no significa «elegido»
La validación de origen RPKI comprueba la coherencia entre prefijo, AS de origen y datos ROA validados. RFC 6811 ofrece la base y RFC 8481 aclara qué rutas se validan y por qué la validación no aplica una política que nadie configuró.
Una ruta válida no es automáticamente la de menor latencia, la comercialmente preferida, una ruta sin fugas, válida bajo BGPsec o válida bajo ASPA. Tampoco prueba la frescura del caché, que ganó el mejor camino, que superó la exportación, que el par la instaló o que el plano de datos la usa.
Los tres modelos separados del borrador preservan esa disciplina. Convertirlos en un único icono verde borraría qué afirmación se verificó.
La política puede cambiar con el contador quieto
La validación de origen se activa por familia y puede limitarse con eligible-prefix-policy. Otro contenedor decide si el estado interviene en la selección. allow-invalid y allow-not-found controlan la elegibilidad de esos estados, con valores predeterminados distintos y un posible alcance adicional por política.
Enviar la comunidad extendida de RFC 8097 es otra decisión. Considerar la validación al exportar es otra más, con su propio tratamiento de rutas no encontradas y su política de prefijos, apoyada en RFC 8893.
Así, la misma distribución de estados puede producir resultados distintos. Cambiar allow-invalid, allow-not-found o una política de exportación puede sustituir candidatos o anuncios sin alterar el total de válidas.
El recibo debe unir la observación con la configuración realmente aplicada y su versión de política. Guardar solo la intención del controlador no basta. RFC 8342 distingue precisamente configuración y estado operacional: pueden divergir por procesamiento, protocolos, hardware o tiempo de propagación.
Una cadena de pruebas
El diseño de evidencia debe separar al menos ocho cosas: entradas de validación y frescura; configuración efectiva; etapa, par, familia y hora de la medición; identidad del conjunto; decisión de mejor camino; conjunto y UPDATE exportados; recepción y aceptación remotas; y resultado de alcance y servicio.
Ningún eslabón prueba automáticamente el siguiente. Datos RPKI frescos no prueban la política aplicada. Un conteo correcto no identifica miembros. Un conjunto no prueba selección. Selección no prueba exportación. Exportación no prueba aceptación. Aceptación no prueba que el tráfico llegó.
Esta separación también acelera incidentes. Si el servicio falla con el total estable, el equipo busca la primera frontera que cambió. El panel quizá nunca estuvo equivocado; simplemente respondía a una pregunta más pequeña que la promesa de negocio.
El documento todavía es un Internet-Draft
Datatracker registra la revisión 02 como borrador activo de la vía Standards Track, con estado I-D Exists. No es un RFC. Las fuentes congeladas no acreditan implementación de proveedor ni despliegue de producción.
Eso impide vender el esquema como capacidad universal, pero no impide mejorar hoy los recibos. La telemetría existente puede conservar etapa, vecino, familia, época de política e identidad del conjunto. El borrador propone una forma común; la necesidad operacional ya existe.
La Minimum Initial Specification y la Running-Code Primacy de Heng Lu aportan el marco: reglas deterministas compartidas no eliminan decisiones locales de selección y exportación. La publicación no crea realidad operacional. La crean implementación, configuración, validación y uso.
La pregunta de cierre correcta no es “¿siguió verde el contador?”. Es “¿qué rutas, en qué etapa, bajo qué política aplicada, se eligieron y anunciaron, y qué hicieron los paquetes?”.
Fuentes
- Registro Datatracker del modelo BGP-RPKI
- Historial de revisiones
- Revisión 02
- Revisión 02 en XML
- Revisión 01
- Modelo YANG de BGP, revisión 21
- Verificación ASPA, revisión 28
- RFC 6811: validación de origen BGP
- RFC 8097: comunidad extendida de estado
- RFC 8205: BGPsec
- RFC 8342: arquitectura NMDA
- RFC 8481: aclaraciones de validación
- RFC 8893: validación RPKI al exportar
- Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Running-Code Primacy
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance

