Resumen

  • RFC 10005 define una comunidad extendida BGP con un valor flotante de cuatro octetos expresado en bytes por segundo; no define cómo obtenerlo ni cómo convertirlo en pesos de tráfico.
  • La política local decide la transitividad, los valores cero o ausentes, la selección entre copias, la regeneración al cambiar el siguiente salto y la ponderación final.
  • Pradosh Mohapatra figura entre seis autores. El alcance contenido de su trabajo colectivo permite interoperar sin confundir el número anunciado con capacidad disponible, estado de la FIB o rendimiento entregado.

La diferencia por un factor de ocho parece trivial hasta que un sistema de inventario etiqueta el dato en bytes, una consola lo presenta en bits y un exportador guarda únicamente el valor redondeado. Durante el incidente, tres equipos observan tres cifras y creen que discrepan sobre la red. En realidad, discrepan sobre una transformación que nadie registró.

La BGP Link Bandwidth Extended Community es compacta por diseño. Su Local Administrator contiene un número IEEE 754 de precisión simple en bytes por segundo. No hay campo para la unidad mostrada, la fecha de medición, el método, el intervalo de validez ni el significado operativo. La exactitud del formato no sustituye esa genealogía.

RFC 10005 se publicó como estándar de la IETF en junio de 2026. Sus autores son Pradosh Mohapatra, Reshma Das, Satya Mohanty, Serge Krier, Rafal Jan Szarecki y Akshay Gattani. El documento normaliza el portador y varios comportamientos que antes variaban entre implementaciones. A la vez, deja fuera deliberadamente el cálculo del valor y el algoritmo de reparto ponderado.

La etiqueta «ancho de banda» no nombra una sola magnitud

Un operador puede entender por ancho de banda la velocidad nominal de una interfaz. Otro puede anunciar la suma de varios caminos remotos. Un tercero puede derivar un peso del número de servidores disponibles. También cabe una señal temporal de mantenimiento. Todos esos valores pueden representarse en bytes por segundo o incluso reutilizar la escala como una preferencia abstracta.

El borrador draft-ietf-bess-ebgp-dmz-10, fechado en abril de 2026 y todavía no convertido en RFC, muestra esta diversidad. Distingue el valor remoto recibido, la velocidad del enlace local y una contribución calculada por el receptor. En un ejemplo, llegan 70 Gbit/s desde detrás del vecino, pero el siguiente salto solo es alcanzable por 50 Gbit/s locales. Una función limitante evita contribuir más de lo que el cuello de botella puede transportar.

El ejemplo no amplía la garantía normativa de RFC 10005. Sirve como advertencia operativa: sumar valores exige saber qué representa cada término. Una agregación de capacidad remota y otra de enlaces locales pueden producir totales distintos con el mismo conjunto de rutas. Si el sistema conserva solo el total, la diferencia queda oculta.

Para cada valor hacen falta un nombre semántico controlado, el sistema fuente, la técnica de medida o configuración, el momento de observación, una ventana de validez y un responsable. «Ancho de banda 70» no basta. «Agregado remoto configurado, observado a las 10:01 y válido cinco minutos» sí puede entrar en una decisión auditable.

Los seis octetos restantes tampoco certifican al originador

La comunidad puede ser transitiva, tipo 0x00, o no transitiva, tipo 0x40; utiliza el subtipo 0x04. Antes del valor aparecen dos octetos de Global Administrator. La recomendación es colocar allí el ASN del router que adjunta la comunidad, pero el campo admite cualquier valor de dos octetos. Para un ASN de cuatro octetos se usa AS_TRANS.

Por tanto, ese administrador no es una firma del productor del dato. No prueba qué equipo midió, qué organización aprobó ni qué dominio posee la capacidad. Tampoco cambia el uso o la semántica de la comunidad. La identidad real debe obtenerse de la sesión BGP, del vecino, del dominio administrativo y del evento de política que adjuntó el atributo.

La forma transitive o no transitive sí afecta cuánto puede viajar la señal. Durante una migración, un equipo antiguo puede reconocer solo una de las dos. Una copia se actualiza y la otra queda obsoleta; más adelante, un receptor encuentra ambas y calcula un peso impropio. Mostrar únicamente la copia seleccionada borra la pista decisiva.

La observabilidad debe conservar tipo, bytes brutos, valor decodificado y edad de cada copia. Cuando convivan dos tipos con valores diferentes, corresponde una alerta, no una conciliación silenciosa.

Cambiar el siguiente salto cambia quién responde por el número

RFC 10005 permite tres acciones cuando un hablante vuelve a anunciar una ruta y modifica el siguiente salto: quitar la comunidad, mantenerla o regenerarla. La implementación debería exponer el comportamiento predeterminado y permitir ajustarlo por sesión. Si el siguiente salto permanece igual, no debería alterar la comunidad.

Mantener conserva la declaración de origen a través de una nueva frontera. Quitar reconoce que ya no debe orientar al receptor. Regenerar produce una nueva declaración local. Las tres decisiones son legítimas; ninguna queda descrita dentro del valor final.

La coincidencia numérica tampoco demuestra continuidad. Un router puede recibir 50, aplicar un límite local y volver a anunciar 50. Los bytes son idénticos, pero la segunda cifra tiene otra autoridad, otra hora y otro método. Sin registrar entrada, función, salida y versión de política, el linaje se pierde aunque el número no cambie.

Esta frontera revela un problema de agencia. El originador define una señal, el intermediario decide transportarla o transformarla, el receptor calcula una proporción y la plataforma la aproxima en hardware. Si el informe final dice solo «50 Gbit/s», ninguna de esas decisiones conserva dueño.

Cero, ausente, inválido y obsoleto no son sinónimos

Cero es válido. Puede emplearse para mantenimiento, pero la política receptora determina su efecto. Frente a una mezcla de cero y valores positivos, una implementación puede excluir la ruta cero, volver al reparto igual o seguir una regla configurada. Si todos valen cero, tampoco existe una única interpretación obligatoria.

La ausencia abre otro caso. Si algún multipath carece de comunidad válida, el comportamiento predeterminado es reparto igual salvo configuración contraria. Los valores negativos no deberían originarse y el receptor los ignora. Una cifra positiva cuyo origen ya caducó sigue siendo formalmente válida, pero está obsoleta.

Un monitor que agrupa los cuatro estados bajo «sin dato» impide responder. Un cero de mantenimiento puede requerir drenar. Una ausencia puede exigir revisar compatibilidad. Un negativo puede exigir corregir el emisor. Un valor viejo puede exigir liberar un filtro de cambios o retirar la evidencia.

Cuando una ruta contiene varias comunidades y participa en reparto ponderado, la elección predeterminada es la menor, incluido cero, aunque la configuración puede modificarla. El expediente debe guardar el conjunto completo, la regla aplicada y el elemento elegido. El número visible por sí solo no prueba que fuera el único.

Una proporción calculada aún no mueve paquetes

Con valores positivos, sus magnitudes o relaciones pueden guiar el reparto. RFC 10005 no define el algoritmo y desaconseja usar el valor en la selección del mejor camino BGP. Primero se determina el conjunto multipath; después, otra lógica decide cómo repartir.

Un receptor puede calcular pesos 1:3. La FIB puede aproximarlos con un número finito de buckets. El hardware puede conservar flujos por hashing resiliente. Una docena de flujos grandes puede inclinar el reparto real aunque el conteo de buckets sea exacto. Son niveles distintos de verdad.

El recibo mínimo enlaza cuatro resultados: comunidades aceptadas, pesos calculados, pesos instalados y tráfico por camino. Añadir pérdida, latencia, ocupación de colas y congestión evita otra confusión: dos caminos pueden recibir la proporción deseada y estar ambos saturados. Reparto conforme no significa capacidad libre.

La inspección del código en ejecución es aquí una disciplina, no un eslogan. La configuración autoriza una conducta; el proceso de routing selecciona datos; la FIB confirma programación; los contadores confirman efecto. Saltar una etapa convierte la intención de un equipo en una afirmación sobre otro.

Limitar cambios crea una deuda de tiempo

Valores que fluctúan con rapidez pueden perjudicar la estabilidad y las operaciones. RFC 10005 recomienda mecanismos para reducir churn. Un umbral o temporizador es razonable, pero la señal deja de avanzar al ritmo de la fuente.

Hay que conservar varias marcas temporales: observación, decisión de anunciar, envío, recepción, cálculo, instalación. También las actualizaciones suprimidas. Sin ellas, un número viejo puede parecer actual simplemente porque su ruta sigue presente.

La exposición de capacidad también puede ser sensible. El RFC aconseja filtrar la comunidad cuando las rutas salen de un dominio administrativo o se dirigen a una red no confiable. Una política de confidencialidad necesita prueba de ejecución: frontera, regla, excepción, versión y resultado. No basta con escribir que el filtrado «debería» ocurrir.

Pradosh Mohapatra representa el límite, no el resultado

RFC 10005 identifica a Pradosh Mohapatra con Google LLC y lo incluye en un grupo de seis autores. En la captura del 1 de septiembre de 2026, el perfil oficial del Datatracker asociado enumeraba once RFC, aunque mostraba la forma antigua «Prodosh Mohapatra». La RFC y la biografía pública de ipSpace usan «Pradosh Mohapatra», que se mantiene como nombre canónico.

La página de ipSpace documenta funciones anteriores en software de routing en Cumulus Networks y Cisco. Es contexto histórico fechado, no prueba de un puesto actual más allá de la afiliación que figura en la RFC, ni de autoridad sobre el consenso de IETF o una implantación concreta.

La contribución importa por su modestia técnica. Mohapatra y sus coautores no convierten un campo de cuatro octetos en certificado de capacidad. Estandarizan una forma de transportar una entrada para política y explicitan las decisiones que cada implementación debe revelar.

Conservar la historia completa del valor

El expediente comienza por ruta, familia, vecino, dominio, tipo, Global Administrator, bytes IEEE 754 y conversión. Continúa con definición, fuente, método, hora, validez y responsable. En cada cambio de siguiente salto añade quitar, conservar o regenerar, con entrada y salida.

Una agregación debe conservar sus componentes y fórmula. La recepción debe conservar la política sobre cero, ausencia, inválidos y copias múltiples. La ejecución debe conservar pesos calculados, FIB, confirmación de hardware y tráfico observado. La operación debe añadir alarma, decisión, reversión y limpieza de datos caducados.

Así, una cifra puede ser discutida sin deshacer el sistema. BGP demuestra qué se anunció. La política demuestra qué decidió el receptor. La FIB demuestra qué quedó programado. El tráfico demuestra qué ocurrió. Solo esa unión permite hablar con rigor de capacidad disponible.

Fuentes