Resumen

  • La revisión 34 exige que un par compatible trate como no disponibles para reenvío todas las rutas asociadas a un Site-ID cuando recibe 0% de disponibilidad física; el efecto equivale a retirarlas una a una, sin transmitir cada retirada.
  • Esas rutas pueden conservar validez en el BGP ordinario. La prueba operativa debe unir origen autorizado, generación del mapa, decisión local, RIB, FIB, flujos y resultado del servicio.

A las 09:14, un sitio de borde pierde su último servidor útil. El router de salida envía un único UPDATE BGP con un Site-ID y disponibilidad física cero. Decenas de prefijos siguen presentes en la tabla BGP del router de entrada, pero dejan de ser candidatos para el tráfico guiado por metadatos. No hay una ráfaga de withdrawals. El panel de routing dice que los caminos existen; el servicio se comporta como si el sitio hubiese desaparecido.

Ese contraste es la aportación operativa de la revisión 34 de BGP Extension for 5G Edge Service Metadata. Fue aceptada el 25 de septiembre de 2026 y lleva fecha de 23 de septiembre. Continúa siendo un Internet-Draft del grupo IDR en estado I-D Exists. La portada dice Standards Track, mientras el campo de estado RFC previsto en Datatracker aparece vacío. No hay document shepherd, Area Director responsable ni telechat; un hito para julio de 2027 apunta a la última llamada del grupo. No es un RFC, una asignación IANA, una implementación ni evidencia de despliegue.

Un solo mensaje hereda muchas asociaciones

El borrador define el Edge Metadata Path Attribute como opcional y no transitivo. Una ruta puede asociar un prefijo de servicio con un Site-ID de 16 bits. Una actualización independiente comunica después propiedades dinámicas del sitio sin repetirlas en cada prefijo. En esa modalidad, el NLRI es el loopback del router de salida, RouteFlag-I vale cero y la actualización actúa sobre las rutas que el receptor ya vinculó al Site-ID. Con RouteFlag-I igual a uno, el mensaje establece la asociación y el porcentaje se ignora.

La revisión 34 endurece el significado del cero. Un speaker compatible debe considerar no disponibles para reenvío todas las rutas asociadas. El texto lo equipara al efecto de retirarlas individualmente, aunque no se envían todas las retiradas. Un par sin Edge Metadata necesita withdrawals BGP convencionales para dejar de utilizar esos caminos.

La equivalencia se refiere al efecto de selección dentro del mecanismo, no a que los estados sean idénticos. El propio borrador permite que una ruta excluida de la selección con metadatos siga siendo válida para alcance BGP ordinario. Un prefijo puede permanecer en el RIB y, a la vez, no ser elegible para una clase de servicio. La separación reduce churn y no confunde salud de aplicación con conectividad. También invalida una conclusión demasiado común: sesión verde más ruta visible no equivale a servicio disponible.

El alcance del cero está en la memoria del receptor

La actualización independiente no enumera los prefijos afectados. Su abanico depende de las asociaciones ruta–Site-ID recibidas antes. Si un ingress conserva 42 rutas para el Site-ID 711 y otro solo 41 porque perdió una actualización anterior, ambos pueden interpretar correctamente el mismo cero y desactivar conjuntos distintos.

Por eso, “recibido Site-ID 711 = 0” no basta como registro. Hace falta una generación de mapa que identifique claves de ruta, instante de vigencia, speaker de origen y puntos de decisión que la reconocieron. El número y un resumen criptográfico del conjunto resuelto permitirían contrastar intención y ejecución sin obligar al protocolo a revelar cada decisión interna.

La generación, el acuse y el resumen son recomendaciones editoriales de operación, no requisitos normativos de la revisión 34. El borrador define conducta de protocolo, no una plataforma de telemetría para toda la flota. Cada operador puede elegir logs locales, un controlador o recibos firmados. La flexibilidad de implementación no debe convertir en invisible la población a la que afectó una orden tan amplia.

Autorizar el origen evita un interruptor remoto

El receptor solo debe aceptar la actualización independiente del router de salida correspondiente o de un route reflector autorizado cuyo Originator-ID identifique ese egress. La condición es crítica: un cero falso puede volver no disponibles todas las rutas asociadas y provocar denegación de servicio.

Una sesión BGP válida no demuestra por sí sola esa autorización. El reflector puede ser un vecino legítimo y llevar un Originator-ID inesperado. El loopback de salida puede estar accesible mientras la sesión pertenece a otra función. El recibo operativo debería conservar par autenticado, AFI/SAFI, Edge Metadata Processing Capability negociada, identidad de salida, Originator-ID si existe, Site-ID, bytes del atributo y veredicto de la política.

La capacidad se negocia bilateralmente por AFI/SAFI. El atributo es opcional y no transitivo; NO_ADVERTISE, el sub-TLV AS-Scope y los filtros habituales limitan la difusión. Los sub-TLV desconocidos se ignoran y la ausencia de un valor nunca debe leerse como cero. Son frenos útiles, pero no acreditan que todos los ingress previstos tengan soporte ni que los pares incompatibles reciban las retiradas ordinarias que aún requieren.

Medición, anuncio y tráfico siguen relojes distintos

Site Physical Availability usa valores de cero a 100; los que quedan fuera de rango se ignoran. El borrador separa el intervalo de medición del intervalo de anuncio y recomienda, salvo configuración distinta, un mínimo de 30 segundos, además de dampening o histéresis. La afinidad de flujo queda a la implementación: un flujo ya fijado a un egress puede continuar hasta que este resulte inalcanzable.

Hay por tanto varias cronologías. El sitio mide cero a las 09:14:00; el egress lo anuncia a las 09:14:12; un ingress lo aplica a las 09:14:13; un flujo persistente termina a las 09:15:00. Resumir todo como “el evento cero” borra la distancia entre medición, distribución, ejecución y experiencia.

La actualización independiente tampoco sirve para resolver next hop. Cambia la elegibilidad para selección de servicio; no afirma que el loopback sea inalcanzable ni que haya convergido BGP. La escalera de evidencia debe guardar cada peldaño: medida de origen, identidad autorizada, generación de asociaciones, capacidad, recepción, conjunto de destino, política, RIB, FIB, tratamiento de flujos y resultado. Saltar de la recepción al impacto sobre clientes es convertir una instrucción en un hecho no observado.

La especificación mínima necesita una frontera ejecutable

La doctrina de Heng Lu propone estandarizar solo lo indispensable para coordinar y dejar decisiones futuras o locales fuera del núcleo común. En este caso, el mínimo puede fijar identidad del sitio, semántica de disponibilidad, origen y alcance; el algoritmo de medición y el ranking siguen siendo locales. La primacía del código en ejecución pide después una prueba en el punto donde ese significado cambia el forwarding.

Para desplegar, conviene exigir un identificador de generación, cantidad y resumen de rutas afectadas, recibo de aplicación por punto de decisión y un flujo canario durante la transición a cero. Son controles propuestos por este análisis, no palabras del borrador. Permiten verificar sin convertir una primera norma en diseño obligatorio de controlador.

El cero gana potencia porque evita retirar ruta por ruta. Esa eficiencia exige recibos más precisos. La tabla BGP puede decir una verdad, el motor de metadatos otra y el usuario experimentar una tercera. Solo hay evidencia operacional cuando las tres se pueden reconciliar.

Fuentes