Resumen
- El 5 de septiembre de 2026 se publicó la revisión 18 de Traffic Steering using BGP FlowSpec with SR Policy. En el corte de esta investigación seguía siendo un Internet-Draft en
AD Evaluation::External Party, no un RFC aprobado. - La versión 17 enviaba a Redirect-to-IP ordinario una instrucción con destino de redirección pero sin un Color válido. La 18 prohíbe ese repliegue cuando hay intención SR incompleta y exige descarte o política local de fallo.
- La ruta FlowSpec válida permanece en la Loc-RIB y puede seguir anunciándose aunque la SR Policy esté caída o no llegue a instalarse. La presencia en el plano de control no acredita el efecto en los paquetes.
- El texto vigente admite que un headend sin soporte ignore el Prefix-SID y aplique Redirect-to-IP. En una red mixta, una misma actualización puede descartarse en un equipo y redirigirse en otro.
- El Working Group Last Call anterior evaluó la revisión 13. Tras la 17, el Area Director pidió a los presidentes de IDR una nueva consulta. La pregunta debe quedar ligada a la versión y a los casos de fallo que realmente se acepten.
La ausencia dejó de ser permisiva
FlowSpec lleva por BGP reglas que seleccionan tráfico y acciones que deben aplicarse. El borrador añade una forma de enlazar ese tráfico con una Segment Routing Policy. El destino de Redirect-to-IP y un Color forman el par (Endpoint, Color). En el modo SRv6 con acción de servicio, un atributo Prefix-SID añade el SID que el equipo de salida debe ejecutar.
La clave es distinguir tres anuncios. Un Redirect-to-IP sin señales SR sigue siendo una redirección convencional. Un destino con Color válido selecciona una policy. Un destino acompañado de Prefix-SID pero sin Color válido ya no es una redirección simple: es una intención SR incompleta.
La revisión 17 resolvía ese tercer caso volviendo a Redirect-to-IP e ignorando el atributo de servicio. La 18 lo invierte. El headend compatible no puede buscar una policy de Color nulo, no puede utilizar Prefix-SID y no puede comportarse como si solo hubiera recibido una redirección ordinaria. El tráfico debe descartarse o someterse a la política local de fallo.
El matiz evita exageraciones. No todo anuncio sin Color se descarta. Si no contiene ninguna señal específica de SR, conserva su significado convencional. La nueva prohibición se activa cuando parte del mensaje dice “use SR” y falta la información necesaria para hacerlo de forma determinada. El borrador prefiere una interrupción visible a una ruta distinta que parezca haber cumplido la intención.
La actualización continúa aunque la acción no exista
El texto separa deliberadamente el ciclo de vida de la ruta y el de la programación. Si la SR Policy está caída, no se puede resolver o no entra en FIB/TCAM, una ruta que supera la validación BGP no se invalida por ese motivo. Permanece en Loc-RIB y sigue siendo elegible para propagación.
La acción de datos debe quedar inactiva. Si la policy está activa pero el SID de servicio no resulta alcanzable, tampoco se permite caer en el camino IP más corto sin aviso. El descarte es la acción local recomendada por defecto, aunque la autoridad operativa puede definir otra. Los componentes no destinados a steering, como una limitación de tasa, siguen vigentes.
Esta separación permite recuperar la acción sin reconstruir el anuncio cuando vuelve la policy. También crea una trampa de observación. Una consola que confirma “ruta recibida” solo prueba el primer estado. Para saber qué servicio recibió el usuario hacen falta la instalación en FIB, la decisión efectiva y un paquete testigo.
La revisión 18 solicita alarmas, razones de fallo y contadores. Durante inundaciones de actualizaciones o agotamiento de recursos, permite limitar, agrupar o suspender registros individuales para salvar el plano de control. Esa excepción es razonable, pero obliga a exponer el estado de supresión y los totales agregados. Cero mensajes no significa cero descartes.
La compatibilidad produce otro resultado
Un headend que implementa FlowSpec y Redirect-to-IP, pero no esta propuesta, no dispone de la nueva categoría “intención SR incompleta”. El Prefix-SID es un atributo opcional transitivo; el equipo puede ignorarlo para su reenvío y aplicar la redirección que sí conoce.
Por eso los mismos bytes no garantizan la misma conducta. El receptor compatible con la revisión 18 ve el intento SR y bloquea el repliegue. El receptor antiguo ve una redirección válida y la ejecuta. La diferencia no necesita un paquete corrupto ni un fallo de sesión BGP: basta una frontera de soporte no documentada.
El proyecto exige controles de anuncio por vecino y servicio, además de filtrado en los límites administrativos. Es una defensa importante, no un descubrimiento automático de capacidades. El emisor debe saber qué dispositivos reconocen la semántica actual y evitar que los atributos lleguen a un grupo heterogéneo sin una política explícita.
La prueba de aceptación debe forzar precisamente los casos incómodos: Color ausente o ilegible, policy caída, SID inalcanzable, fallo de programación y receptor sin soporte. Para cada uno hay que registrar Loc-RIB, propagación, FIB, contador de descarte o redirección, tráfico testigo, alarma, supresión y recuperación. Probar solo un enlace correcto no responde a la noticia de la revisión 18.
La versión 13 no puede votar por la 18
El shepherd write-up describe un WGLC corto, de una semana, para la revisión 13, con apoyo positivo. Después, la evaluación del Area Director modificó el documento de manera importante: aparecieron dos modos de operación, una secuencia de resolución, una matriz más completa, reglas de convivencia, nuevas funciones de servicio y requisitos operativos y de seguridad más extensos.
El 26 de agosto, cuando los autores habían publicado la revisión 17, el Area Director pidió a los presidentes de IDR que consultaran de nuevo al grupo antes de avanzar. Datatracker situó el expediente en AD Evaluation::External Party. La revisión 18, publicada el 5 de septiembre, cambió otra vez la parte donde se materializa el daño: pasó de redirigir a bloquear el repliegue en la intención incompleta y añadió el fallo de alcance del SID.
La nueva consulta no es una repetición burocrática. Un participante puede apoyar la interoperabilidad básica y rechazar que la respuesta predeterminada sea pérdida de tráfico. Otro puede considerar que un desvío no autorizado viola un compromiso más importante. El rough consensus sirve para conocer y resolver esas objeciones técnicas; no se hereda de una tabla anterior con el resultado opuesto.
La pregunta debe nombrar revisión 18 y sus decisiones: qué hace una Color ausente, qué conserva la Loc-RIB, qué ocurre si policy o SID fallan, quién define la política local y cómo se comporta el equipo sin soporte. El acta debe preservar razones y objeciones, no reducirlas a un “sí” sin versión.
Las pruebas de 2021 tienen fecha
La sección de implementaciones informa de cuatro routers y cuatro controladores que participaron en pruebas conjuntas organizadas por China Mobile entre julio y octubre de 2021. También afirma uso productivo en su backbone desde agosto de 2022. Es evidencia pertinente, acompañada de una advertencia explícita: los datos fueron aportados por colaboradores, no se verificaron de forma independiente y no son un aval de la IETF.
Además, la cronología limita lo que pueden demostrar. El expediente consultado no conecta aquellas pruebas con la matriz de la revisión 18, el nuevo caso de SID inalcanzable, las reglas de sustituir o añadir un SID ni la divergencia entre receptores compatibles y antiguos. Un ensayo puede seguir siendo válido para lo que probó sin convertirse en prueba de una semántica escrita años después.
La solución es añadir versión a la evidencia. Cada implementación debe declarar compilación, revisión, funciones, combinaciones negativas, capacidad del peer y resultado de paquete. Así, una repetición actual complementará el registro en vez de disfrazar la edad de la prueba.
Un recibo para la decisión y otro para el paquete
El registro de consenso debe incluir el hash de la revisión, fechas, pregunta, archivo de respuestas, objeciones y evaluación de los presidentes. El registro de interop debe utilizar la misma revisión y una tabla por caso: redirección convencional, modos 1 y 2 correctos, Color inválido, policy caída, SID inalcanzable y programación agotada.
Cada fila necesita dos resultados cuando haya parque mixto: equipo compatible y no compatible. Debe separar ruta aceptada, anuncio reenviado, acción instalada y paquete observado. Contadores, alarmas y supresión de logs completan la cadena.
El despliegue añade propietario, inventario de capacidades, filtros, rangos de SID autorizados, política local, reintento, canario y condición de rollback. Los identificadores sensibles pueden ocultarse, pero la versión y el resultado no. Las correcciones se anexan para que una prueba fallida no desaparezca cuando se repita.
La especificación mínima de Heng Lu aporta solo una disciplina editorial: el significado compartido ha de ser pequeño, determinista y verificable; las decisiones futuras pueden seguir siendo locales si conservan responsable y prueba. El título IETF no debe elegir entre descarte y desvío por un operador.
La revisión 18 puede haber elegido mejor que la 17. Antes de darle autoridad, el grupo debe consentir esa elección concreta y los operadores deben demostrar que un parque mixto no convierte la misma orden en dos servicios distintos.
Fuentes
- IETF Datatracker — Traffic Steering using BGP FlowSpec with SR Policy
- IETF — texto de la revisión 18
- IETF — texto de la revisión 17
- IETF Author Tools — comparación entre las revisiones 17 y 18
- IETF Datatracker — historial del documento
- Lista IDR — solicitud de otra consulta de consenso
- IETF — informe del shepherd
- RFC 8955 — Dissemination of Flow Specification Rules
- RFC 9256 — Segment Routing Policy Architecture
- RFC 7942 — Improving Awareness of Running Code
- RFC 7282 — On Consensus and Humming in the IETF
- Heng Lu — Minimum Initial Specification
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