Resumen

  • RFC 10005 permite originar un valor Link Bandwidth de cero y cita el mantenimiento como ejemplo, pero deja al receptor la política para valores cero, mixtos o ausentes.
  • El drenaje sólo está demostrado cuando el valor efectivo llega, la ruta sale o cambia dentro del conjunto multipath, la FIB refleja el peso esperado y los contadores confirman que el tráfico se desplazó sin sobrecargar otra salida.

El plan de cambio parecía determinista: anunciar cero, esperar a que los flujos abandonaran el enlace y comenzar la intervención. El UPDATE llegó al vecino y la sesión BGP siguió estable. Sin embargo, el receptor tenía configurada una política que, ante una mezcla de valores cero y no cero, volvía al reparto igual. La ruta que debía quedar vacía conservó tráfico.

No hubo paquete malformado ni incumplimiento automático del estándar. Hubo dos autoridades distintas: el emisor expresó una preferencia; el receptor decidió cómo convertirla en forwarding. El error operativo fue redactar la primera como si fuera la segunda.

RFC 10005, publicado en junio de 2026 como Proposed Standard, hace explícita esta separación. Un valor cero es válido y no debe considerarse malformado. Puede usarse para indicar que un camino no debería atraer tráfico durante mantenimiento, pero el comportamiento final depende de la política local del receptor.

El campo es preciso y su significado sigue siendo local

Link Bandwidth tiene forma transitiva, Type 0x00, y no transitiva, Type 0x40; ambas usan SubType 0x04. El valor ocupa cuatro octetos como flotante IEEE 754 de 32 bits y se expresa en bytes por segundo. El Global Administrator ocupa dos octetos, suele llevar el ASN del router que adjunta la comunidad y usa AS_TRANS si el ASN no cabe. Ese campo no altera la semántica ni autentica al originador.

La precisión del formato evita ambigüedad al decodificar. No convierte el número en una medición. El propio RFC declara fuera de alcance cómo se calcula o determina la capacidad. El borrador de casos de uso admite velocidad local descubierta, valor remoto, una función de ambos, capacidad agregada e incluso número de servidores.

Por eso cero también puede tener historias distintas. Puede ser una señal manual de mantenimiento, la consecuencia de que falte una fuente necesaria o el resultado de una función que no pudo calcularse. Guardar sólo el número borra la causa y hace que dos situaciones distintas activen la misma automatización.

Cuatro estados que un playbook no debe mezclar

Cuando todos los caminos contribuyentes tienen valores no nulos, el receptor puede usar los valores o su proporción como pesos. Cuando hay una mezcla de cero y no cero, el RFC ofrece ejemplos, no una única consecuencia: excluir los caminos con cero mientras exista alguno no nulo, o volver a reparto igual. Si todos son cero, vuelve a decidir la política local.

La ausencia es diferente de cero. Si alguno de los caminos no lleva una comunidad válida, debería usarse reparto igual salvo configuración local contraria. Un valor negativo tampoco equivale a cero: no debería originarse y la comunidad que lo contiene se ignora al recibirla. Si aparecen varias comunidades, el comportamiento por defecto es escoger la menor, incluido cero, ignorando la transitividad; la configuración puede modificarlo.

Estas cuatro clases—cero, ausente, negativo y múltiple—necesitan pruebas separadas. Un sistema de automatización que normaliza todas como “sin capacidad” destruye justamente la información que el RFC conserva.

Además, Link Bandwidth no debería entrar en la selección del best path BGP. Sólo puede ponderar rutas que ya forman un conjunto multipath. Ver el cero en show route no demuestra que la ruta fuera candidata, que saliera del conjunto ni que el hardware recibiera peso cero.

El camino de la señal tiene puntos de reescritura

La comunidad puede adjuntarse o modificarse en Adj-RIB-In y Adj-RIB-Out. Si un router cambia el next hop al volver a anunciar, puede eliminar, conservar o regenerar el valor y debería ofrecer control por sesión. Si no cambia el next hop, no debería tocar la comunidad.

Un drenaje iniciado en un borde puede, por tanto, ser reinterpretado en varios lugares. Un import policy reemplaza cero; un cambio de next hop regenera un valor desde interfaces locales; un export policy retira la forma no transitiva; un equipo antiguo entiende sólo una de las dos variantes. Cada transformación puede ser legítima y aun así invalidar la expectativa original.

Durante una migración, el emisor puede incluir simultáneamente las formas transitiva y no transitiva, con valores que deberían coincidir. Si un equipo antiguo actualiza sólo una, receptores diferentes pueden aplicar pesos incompatibles. Actualizar únicamente el route reflector no soluciona esa interoperabilidad: el RFC exige soporte en los hablantes que envían o reciben.

Drenar una ruta puede llenar otra

Incluso cuando cero funciona como esperaba el emisor, el cambio puede mover el problema. El camino restante recibe más flujos, pero su capacidad local puede ser menor que el valor remoto que anuncia. El ejemplo central del borrador de casos de uso muestra un remoto de 70 detrás de un enlace local de sólo 50; repartir 70% puede provocar congestión.

El receptor puede elegir como contributing bandwidth el valor remoto, la velocidad local o una función de ambos, por ejemplo el mínimo. Esa decisión es local. Para un mantenimiento seguro, la previsión debe simular tanto la retirada del camino como la capacidad real de los supervivientes.

Las implementaciones confirman la diversidad. Juniper documenta que el valor configurado no es tráfico observado y que las proporciones pueden importar más que una velocidad física. Cisco expone DMZ Link Bandwidth y tráfico ponderado. Arista permite regeneración por vecino. Son superficies de control reales, no equivalencias garantizadas entre versiones.

La prueba de drenaje es una cadena de retorno

Antes del cambio, conservar el UPDATE y la política efectivos, el conjunto multipath y los pesos de hardware. Definir cuánta reducción de tráfico constituye drenaje, durante cuánto tiempo y con qué margen. Anunciar cero y observar la ruta post-policy en cada receptor relevante.

Después, leer la FIB y los contadores, no sólo el RIB. Verificar bytes, paquetes, flujos persistentes, colas, pérdida y latencia en el camino drenado y en los restantes. Comprobar el resultado de aplicaciones con sesiones largas, que pueden sobrevivir a un cambio de peso. Registrar el momento exacto en que cada plano cambió.

La primacía del código en funcionamiento de Heng Lu exige esta devolución: la norma y la intención no sustituyen el resultado observado. Su especificación inicial mínima justifica reglas comunes para formato y seguridad, pero mantiene la decisión de tráfico y su responsabilidad cerca del operador.

El emisor anunció cero. Hasta que el receptor y los contadores respondan, el drenaje sigue siendo una solicitud.