Resumen
- La revisión 03 del borrador de GROW sobre terminología de operaciones de enrutamiento es un inventario descriptivo, no una autoridad que convierta palabras habituales en condiciones ejecutables.
- Una
Full Tablesolo puede evaluarse respecto de una familia de direcciones, un hablante, una política de importación, un momento y una definición operativa de la tabla global; incluso entonces, no prueba instalación en el plano de reenvío ni entrega de tráfico.
La alarma se apagó a las 03:17. El colector mostraba una cifra cercana a la esperada, el vecino BGP permanecía establecido y el panel escribió full table: yes. Dos horas después, un servicio seguía sin alcanzar varios destinos IPv6. Nadie había mentido: el panel había contado rutas IPv4 aceptadas por un router concreto. El equipo de incidente había leído la etiqueta como una afirmación sobre toda la red.
Ese salto entre observación y conclusión es precisamente el tipo de problema que deja al descubierto la revisión 03 de Currently Used Terminology in Global Routing Operations. Tobias Fiebig y Wolfgang Tremmel presentaron esta revisión el 2 de octubre de 2026. El texto reúne expresiones que se usan hoy en operaciones de enrutamiento y advierte que no constituye una fuente autoritativa de terminología correcta. Describe usos observados en un momento determinado, sujetos a cambio, y admite que una misma palabra aparezca en contextos distintos con significados distintos.
La ficha de Datatracker la sitúa como Internet-Draft activo del grupo GROW en el flujo IETF. Su estado previsto es Informational y vence el 5 de abril de 2027. No tiene RFC, Area Director responsable, shepherd, telechat ni resultado final del proceso. No solicita acciones de IANA. Su apartado de seguridad dice que, al describir terminología sin formular recomendaciones, el documento no introduce consideraciones de seguridad.
Esa afirmación describe el alcance del borrador. No concede seguridad automática a un sistema que importa sus etiquetas. Un glosario puede ser inocuo; una automatización que transforma full table, peer, cone o blackholing en permisos de acción puede no serlo. La consecuencia nace cuando una palabra coordinadora ocupa el lugar de una condición probada.
«Todas las rutas» no existe sin un marco
El borrador define Full Table como una tabla que contiene una ruta hacia todos los prefijos de la Global Routing Table y que no contiene una ruta por defecto. Esa definición es útil para conversar. Para ejecutarla, sin embargo, hay que responder qué cuenta como todos, dónde se observa y cuándo.
IPv4 e IPv6 tienen universos distintos. Un router puede recibir una tabla completa de una familia y ninguna de la otra. Dos vecinos pueden anunciar conjuntos diferentes por contrato o política. Dos colectores pueden discrepar por tiempo de propagación, filtros, reinicios o alcance de visibilidad. La propia idea de Global Routing Table es una vista operacional construida, no un objeto que llega con un sello universal.
La política de importación cambia la respuesta. Un hablante puede recibir una ruta y rechazarla; puede aceptar varias y seleccionar una; puede ocultar rutas por límites de memoria, validación de origen o reglas locales. Un contador anterior a la política responde una pregunta diferente de uno posterior. Escribir solo full=true borra esa diferencia.
También importa el instante. Durante la convergencia, una instantánea puede parecer completa entre dos retiros y dos anuncios. Un umbral numérico puede coincidir con el histórico mientras faltan prefijos importantes y sobran rutas más específicas. El número de entradas no prueba cobertura del conjunto esperado.
Por eso una afirmación operable necesita al menos: familia de direcciones; router o colector; vecino o fuente; etapa de política; instante e intervalo de estabilidad; definición o conjunto de referencia; y evidencia reproducible. La palabra puede seguir apareciendo en la interfaz. Debajo debe existir un predicado con coordenadas.
La RIB no es la FIB y la FIB no es la entrega
Incluso una afirmación bien delimitada sobre la tabla BGP describe el plano de control. No demuestra que todas las rutas seleccionadas estén instaladas en el plano de reenvío. La recursión puede fallar, una plataforma puede quedarse sin recursos, una política de instalación puede excluir una ruta o el proceso de programación puede ir retrasado.
La FIB, a su vez, no certifica el trayecto de extremo a extremo. La interfaz de salida puede estar activa mientras un enlace remoto descarta paquetes. Una ruta puede existir y conducir a un agujero negro. El servicio de aplicación puede fallar por una capa posterior. Cada paso necesita su propio recibo.
RFC 4271 describe un proceso de decisión local. Un hablante selecciona rutas según sus atributos y política. Esa decisión no es un referéndum de Internet ni una observación de paquetes. Cuando un panel mezcla selección local, instalación y alcance bajo una única luz verde, la luz expresa comodidad, no realidad.
BFD ofrece otro ejemplo de evidencia estrecha. RFC 5880 permite detectar con rapidez la pérdida de un camino de reenvío entre sistemas configurados. La revisión 03 mejora su definición respecto de la versión anterior: habla de comprobar si un vecino es alcanzable y de señalar la pérdida de esa alcanzabilidad a protocolos como BGP, en lugar de afirmar que el vecino está «vivo». Alcanzable no significa servicio entregado; tampoco identifica por sí solo la causa de una caída.
La revisión 03 corrige lenguaje, no crea una ontología eterna
La nueva revisión amplía abreviaturas, definiciones y referencias. Refina BFD y la presentación de atributos BGP, y añade o aclara entradas como BGP, EGP, IGP, EIGRP, IS-IS, OSPF y RIR. Es trabajo editorial sustantivo que mejora la orientación de quien lee otros borradores.
Pero el mismo documento insiste en su carácter descriptivo. Una mejora de redacción no convierte la última revisión en verdad retroactiva. Un ticket de 2024 pudo usar full table con una convención local distinta. Si un sistema vuelve a interpretar todos los registros antiguos según la revisión 03, fabrica precisión histórica.
La procedencia debe acompañar al dato: nombre del vocabulario, revisión, contexto, identificador de sentido y, si hubo una migración, reglas y evidencia de la correspondencia. Cuando el sentido original no puede recuperarse, la respuesta correcta es «ambiguo», no la opción más probable.
Esa disciplina permite actualizar el lenguaje sin reescribir decisiones pasadas. También hace posible comparar versiones: qué cambió, qué entradas se dividieron, qué afirmaciones ganaron límites y qué consumidores todavía dependen de una cadena desnuda.
Converged es otra palabra con perímetro local
El borrador describe la convergencia desde el trabajo de un hablante BGP que aprende rutas, las evalúa y encuentra una preferida para cada destino. Un router puede terminar ese proceso mientras otros siguen intercambiando actualizaciones. La programación de hardware puede ir detrás. El tráfico puede alternar entre caminos. Un monitor externo puede seguir viendo inestabilidad.
Una bandera converged=true debería nombrar el sujeto y el criterio de parada. ¿No cambió la Loc-RIB durante un intervalo? ¿Terminó la cola de actualización? ¿La FIB coincide con la selección? ¿Cesaron los cambios desde varios puntos de observación? ¿La aplicación recuperó el servicio? Son preguntas relacionadas, no equivalentes.
La tentación de un único estado global aumenta con los agentes autónomos. Un agente puede leer que el router convergió y cerrar el incidente, retirar una mitigación o iniciar otra migración. Si la evidencia solo cubre un hablante, la automatización expande el alcance sin autorización factual.
La solución no es esperar certeza total. Es conservar la incertidumbre por capa. control_plane_stable_at_router_A puede ser verdadero mientras network_wide_stability permanece desconocido y service_delivery falla. Un sistema útil permite esas combinaciones.
Una palabra puede cambiar el tipo de dato
Cone muestra un problema diferente. El borrador lo presenta como el conjunto recursivo de AS downstream y señala que, según el contexto, también puede abarcar el conjunto conjunto de prefijos que originan. Un conjunto de ASN y un conjunto de prefijos no es el mismo tipo.
Si una API recibe cone sin indicar miembros y método de cálculo, una operación de pertenencia puede devolver una respuesta sintácticamente correcta sobre el universo equivocado. La relación entre AS y prefijos cambia con el tiempo y con el punto de observación. Para pasar de un conjunto al otro hace falta una unión explícita y fechada.
Peer también cambia de capa. En el apartado de relaciones describe a dos AS conectados que intercambian sus propias rutas y las de sus downstreams. En el apartado de enrutamiento puede ser simplemente un vecino BGP que intercambia NLRI. Una sesión establecida no prueba una relación comercial o de exportación; una relación puede subsistir durante una caída de sesión.
RFC 9234 permite negociar Roles BGP para reducir fugas de rutas. Es una prueba específica y valiosa, pero no sustituye el contrato, la configuración aplicada, el filtro efectivo ni las rutas observadas. Cada pieza atestigua una proposición distinta.
Network edge y Provider Edge repiten el patrón. El último router bajo control administrativo no es necesariamente un PE MPLS. Una etiqueta espacial no basta para elegir una plantilla funcional. El inventario debe separar frontera administrativa, rol de servicio, interfaz, operador y periodo.
Una categoría de incidente no prueba intención
El borrador define un route hijack como el anuncio de una ruta que un AS no está autorizado a anunciar y añade que puede deberse a una configuración accidental o a una acción maliciosa. La clasificación técnica no decide la intención.
RFC 7908 trata las fugas como propagación más allá del alcance previsto, en contra de las políticas esperadas. Para saber qué alcance se esperaba hacen falta pruebas de relación, autorización y configuración. El camino observado demuestra propagación; no reconstruye por sí solo quién aprobó qué.
RPKI estrecha otra proposición. RFC 6480 describe la arquitectura de certificación y RFC 9582 los ROA que autorizan a un AS a originar prefijos dentro de un alcance. Un origen válido no demuestra que el camino respete políticas de relación, que la ruta esté instalada o que los paquetes lleguen. Tampoco un estado invalid o not-found es un mandato universal independiente de la política local.
Blackholing puede ser el síntoma de paquetes descartados silenciosamente o una acción deliberada mediante comunidades para pedir a otros que descarten tráfico. Un sistema no debe transformar una alerta de pérdida en una orden de descarte solo porque ambas usan la misma palabra.
Depeering suele significar retirar sesiones con un AS vecino. El recibo de esa configuración no prueba que todo tráfico hacia o a través de la organización haya cesado. Puede existir otra interconexión, tránsito, ruta por defecto o estado residual. El efecto debe observarse por separado.
El contrato mínimo para un término operativo
Antes de que una etiqueta descriptiva autorice una acción, el registro debería incluir: término literal; vocabulario y revisión; identificador estable del sentido; contexto; sujetos y dirección; punto de observación y tiempo; fuente o evidencia; acción solicitada y principal autorizado; incertidumbre y lecturas rivales.
No se trata de construir una taxonomía universal antes de operar. Minimum Initial Specification pide el sobre más pequeño que impida el error peligroso. Un panel puede mostrar «tabla completa». Su API debe exponer que la afirmación concierne a IPv4, al router A, después de la política X, a las 03:17, comparada con el conjunto Y.
Running-Code Primacy exige ensayos donde los significados incompatibles intenten cruzarse. Enviar una tabla IPv4 a una condición de cobertura dual-stack debe fallar. Declarar convergencia local mientras otro observador cambia debe mantener el estado global desconocido. Entregar un cone de ASN a una operación sobre prefijos debe ser rechazado.
También hay que probar las transiciones. ¿Qué ocurre cuando cambia la revisión del vocabulario? ¿Cuando un campo antiguo carece de sentido? ¿Cuando dos fuentes discrepan? ¿Cuando el recibo de configuración aparece antes que la observación? Los estados intermedios son el lugar donde una palabra suele adquirir más autoridad de la que merece.
La modestia del glosario es una ventaja
La revisión 03 es valiosa porque no finge eliminar la diversidad del habla operativa. Recoge expresiones, mejora definiciones y deja visibles sus contextos. Ayuda a detectar supuestos que un equipo experimentado completa mentalmente.
La responsabilidad empieza en el consumidor. Un inventario debe tipar roles. Un motor de política debe pedir predicados. Un agente necesita límites de capacidad. Un proceso de incidentes debe separar observación, causa, intención, acción y resultado. Ninguno puede delegar esa tarea a una palabra cómoda.
En las capas de realidad de Heng Lu, la etiqueta es coordinación simbólica; la política y la relación son objetos institucionales; la sesión y la configuración son estados ejecutables; la propagación y la entrega son observaciones. El error aparece cuando una capa se hace pasar por la siguiente sin una unión de evidencia.
La tabla de las 03:17 sí estaba completa bajo una definición estrecha. Esa afirmación no era inútil. Era insuficiente para cerrar un incidente IPv6 y declarar entrega global. La corrección no consiste en prohibir «completa», sino en conservar sus coordenadas hasta que el sistema pueda demostrar exactamente qué estaba completo, dónde y para qué decisión.
Sources
- https://datatracker.ietf.org/doc/draft-ietf-grow-routing-ops-terms/
- https://datatracker.ietf.org/doc/draft-ietf-grow-routing-ops-terms/history/
- https://datatracker.ietf.org/api/v1/doc/document/draft-ietf-grow-routing-ops-terms/
- https://datatracker.ietf.org/doc/draft-ietf-grow-routing-ops-terms/references/
- https://datatracker.ietf.org/doc/draft-ietf-grow-routing-ops-terms/referencedby/
- https://www.ietf.org/archive/id/draft-ietf-grow-routing-ops-terms-03.txt
- https://www.ietf.org/archive/id/draft-ietf-grow-routing-ops-terms-03.html
- https://www.ietf.org/archive/id/draft-ietf-grow-routing-ops-terms-03.xml
- https://www.ietf.org/archive/id/draft-ietf-grow-routing-ops-terms-02.txt
- https://datatracker.ietf.org/wg/grow/about/
- https://www.rfc-editor.org/rfc/rfc4271.html
- https://www.rfc-editor.org/rfc/rfc9234.html
- https://www.rfc-editor.org/rfc/rfc7908.html
- https://www.rfc-editor.org/rfc/rfc6480.html
- https://www.rfc-editor.org/rfc/rfc9582.html
- https://www.rfc-editor.org/rfc/rfc7454.html
- https://www.rfc-editor.org/rfc/rfc5880.html
- https://www.rfc-editor.org/rfc/rfc5925.html
- https://www.rfc-editor.org/rfc/rfc8174.html
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
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
