Resumen
- La RFC 8966, de Juliusz Chroboczek y David Schinazi, considera local la política que convierte el coste de un enlace y la métrica anunciada por un vecino en una nueva métrica. Sólo exige que un coste infinito produzca infinito y que el resultado sea estrictamente mayor que la métrica recibida.
- La monotonía protege la lógica de evitación de bucles. No prueba que el camino tenga más ancho de banda, menor coste económico, menor latencia útil, alcance actual o mejor resultado para un usuario. RFC 9616 muestra que una muestra de RTT puede ser exacta y, aun así, no ser apta para selección directa.
El mismo número puede cumplir funciones distintas
Un número reducido suele viajar mal. Sale de una tabla de rutas, llega a un panel y termina presentado como el “mejor” camino. En ese traslado se pierden el vecino que lo anunció, el coste calculado localmente, la interfaz, la política y la condición que la ruta debía cumplir antes de poder ser seleccionada.
La RFC 8966 no autoriza esa abreviatura. Babel es un protocolo de vector distancia que evita bucles. Cada nodo combina una métrica recibida con un coste local. La especificación permite estrategias distintas entre nodos e interfaces. No exige que todos midan idéntica latencia, pérdida, saltos o gasto. Exige una propiedad de la operación: si se añade un coste local finito, la métrica resultante debe aumentar; si el coste es infinito, el resultado debe ser infinito.
La propiedad hace visible el límite de seguridad que los nodos comparten. No crea una escala pública de valor. Una ruta con una métrica baja puede ser una elección correcta para un dominio configurado de una manera determinada y no decir nada, por sí sola, sobre otra topología, una transferencia de datos real o una aplicación que responda.
Convergencia sin diploma de óptimo
La RFC separa la monotonía estricta de la distributividad por la izquierda. La primera es esencial para evitar bucles persistentes. La segunda se recomienda, pero no es indispensable para converger sin bucles. Cuando falta, el protocolo puede converger y aun así no alcanzar un óptimo global; incluso puede no existir tal óptimo.
Esa frase impide convertir la métrica en un árbitro central. Las políticas locales pueden diferir y conservar el invariante que evita la vuelta infinita. La selección también tiene frenos: una ruta infinita o no factible no se selecciona, y un número de secuencia mayor no debe ganar sólo por ser más reciente. La RFC advierte que esa lectura puede provocar oscilaciones y, con algunas métricas, agujeros negros persistentes. Para métricas que cambian sin cesar, recomienda histéresis.
La histéresis no es un adorno de interfaz. Es una manera de pedir evidencia sostenida antes de cambiar una decisión. Tampoco es una garantía de servicio, pues sólo regula la transición dentro del algoritmo.
La extensión RTT conserva la distinción
RFC 9616, firmada por Baptiste Jonglez y Chroboczek, parte de que Babel no impone un único algoritmo de métricas. Ofrece una extensión basada en RTT porque el conteo de saltos o la pérdida de paquetes puede elegir mal en ciertas topologías de túneles o VPN. Su punto más útil es negativo: las muestras de RTT pueden ser precisas, pero ser ruidosas y producir oscilación si se usan directamente. Por eso el RFC define cómo transformar las muestras en coste y cómo aplicar histéresis.
También limita el caso: el retraso simétrico debe ser un buen predictor de si el enlace conviene para el tráfico de encaminamiento. No demuestra una latencia universal ni una experiencia de usuario. RFC 8965, escrita por Chroboczek, describe la robustez de Babel ante métricas nuevas o fluctuantes, pero también sus límites de actualizaciones periódicas y tabla de rutas completa.
El perfil público de IETF vincula a Chroboczek con las RFC 8965, 8966 y 9616. Es una atribución documentada, no prueba de que controle las decisiones de una red, un producto o un despliegue.
Límites de la evidencia
Las fuentes no identifican un dominio Babel hoy activo, un túnel operativo, una ruta seleccionada en una red nombrada, una medición actual de RTT, capacidad, precio, postura de seguridad ni resultado de entrega. El registro útil no es una etiqueta de “mejor ruta”, sino un recibo con familia y versión de métrica, alcance local, entradas, transformación, factibilidad, histéresis y condición de selección.
Fuentes
- Registro RFC Editor de RFC 8965
- RFC 8965 — Applicability of the Babel Routing Protocol
- Registro RFC Editor de RFC 8966
- RFC 8966 — The Babel Routing Protocol
- Registro RFC Editor de RFC 9616
- RFC 9616 — Delay-Based Metric Extension for Babel
- Perfil IETF Datatracker de Juliusz Chroboczek
- Heng Lu — Minimum Initial Specification
- Heng Lu — 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
