Resumen

  • draft-ietf-idr-fsv2-ip-basic-08 incorpora orden de usuario, componentes obligatorios u opcionales y cadenas de filtros dependientes, pero cada nodo decide localmente si puede instalar la regla.
  • La operación necesita un recibo por destino: objeto recibido, capacidades, validación, orden efectivo, elementos omitidos, estado instalado, contadores, retirada y resultado sobre paquetes. La propagación BGP sólo acredita el primer tramo.

La red de pares respondió; los equipos no hicieron lo mismo

El sistema anuncia un filtro de emergencia. Los route reflectors lo propagan y todos los vecinos esperados lo reciben. Desde el control plane, la tarea parece completa.

Un borde instala la coincidencia y todas sus acciones. Otro no admite un componente obligatorio y declara inválido también el grupo dependiente. Un tercero omite un componente opcional e instala el resto. Un nodo antiguo conserva y retransmite una comunidad de acción que no entiende.

El objeto recorrió la red; su efecto se fragmentó. La revisión 08 del borrador, fechada el 28 de septiembre de 2026, describe ese límite y lo resume sin rodeos: BGP sigue sin una función de action-reply.

Recibir un UPDATE prueba transporte de política, no ejecución de política.

Un borrador vigente no es una implantación

Datatracker registra la revisión 08 como Internet-Draft activo del grupo IDR y la mantiene en I-D Exists. El texto indica Standards Track, mientras la ficha no especifica el estado RFC previsto. Quedan valores AFI, SAFI y tipos por asignar, notas editoriales y trabajo posterior para resolver por completo ciertas interacciones entre acciones.

La precisión importa. El documento muestra el diseño que discute el IETF, no demuestra soporte en un producto ni despliegue en una red identificada.

RFC 8955, RFC 8956 y RFC 9117 forman la base de FSv1. FSv2 usa familias distintas, de modo que ambas versiones pueden convivir como “barcos que pasan de noche”. En una transición habrá nodos con las dos, con una o con ninguna.

Sin embargo, el paquete sólo encuentra una lista efectiva de reglas en cada equipo. Separar familias en BGP no armoniza automáticamente esa lista.

User Order es intención transportada

Cada NLRI de FSv2 lleva un User Order de 32 bits; los valores menores tienen mejor precedencia. Así el operador puede corregir un orden predeterminado que no expresa su objetivo.

El orden cambia el resultado. Una excepción específica antes de un descarte amplio no equivale a instalarla después. El borrador recomienda situar FSv2 antes de FSv1 y guardar ambas familias en una base común con valores que preserven esa prioridad.

Pero el receptor debe combinar reglas locales, resolver empates, validar coincidencias y acciones y programar software o hardware. BGP no devuelve al originador el orden que terminó activo. El recibo debe incluir tanto el orden anunciado como el instalado.

DFC no es un commit distribuido

Dependent Filters Chain intenta impedir una instalación parcial peligrosa. El ejemplo del borrador combina una regla específica que permite SMTP y marca DSCP con otra más amplia que descarta. Si un equipo no puede marcar y sólo instala el descarte, bloquea tráfico que debía pasar.

Un DFC no nulo asocia reglas que comparten destino local. Cuando una es inválida en un dispositivo, las demás del mismo DFC también quedan inválidas allí y no se instalan.

El alcance termina en ese dispositivo. Otro puede considerar válido el conjunto; un reflector puede revisar sólo la sintaxis; un nodo en actualización puede ignorar la semántica nueva. DFC no responde al emisor, no compara el parque y no revierte entradas ya activas en otros lugares.

Es una coordinación de elegibilidad local, no una transacción atómica de red.

Un componente opcional puede ensanchar la regla

Si un equipo no admite un componente obligatorio, la regla es inválida. Si el componente está marcado como opcional, puede retirarlo e instalar el resto como entrada válida.

Eso ayuda al despliegue gradual y a la vez puede cambiar el conjunto de paquetes. Un prefijo acompañado por un calificador nuevo y restrictivo será preciso en un nodo moderno; al desaparecer el calificador en uno antiguo, la acción restante puede cubrir más tráfico.

La omisión debe aparecer en el recibo: qué faltó, qué coincidencia quedó, qué acción sobrevivió y quién aceptó esa variante. “Válida” no significa “idéntica”.

Para las acciones, la revisión permite que los defaults o la configuración decidan si una acción no instalable invalida toda la regla. También deja mecanismos avanzados de orden y validez para trabajo futuro. Una flota mixta no puede presumir un resultado común.

El significado puede detenerse aunque los bytes sigan

Las acciones viajan asociadas mediante Extended Communities. RFC 4360 define su transporte y transitividad. Un dispositivo que desconoce una acción transitive puede propagarla correctamente.

El borrador señala que el nodo antiguo quizá ni siquiera sepa que se solicitó esa acción. Ejecutará en best effort sólo lo que reconoce. La política sobrevive como objeto BGP, pero no como semántica local uniforme.

Una mitigación que pide marcar, muestrear y redirigir puede quedar reducida a un subconjunto. La revisión analiza interacciones múltiples, pero la solución completa depende de un futuro contenedor. Ver la comunidad en BGP no prueba el conjunto ordenado en el dataplane.

Validar no equivale a programar

FSv2 comprueba estructura del NLRI, propiedades de ruta y acciones. La factibilidad por defecto depende de un prefijo de destino y de rutas unicast relacionadas, aunque una configuración explícita puede relajar partes del proceso.

Si la malformación impide recuperar límites, puede reiniciarse la sesión. Otros fallos usan treat-as-withdraw según RFC 7606. La revisión advierte que una retirada malformada de una ruta antes válida puede dejar una regla atascada y exige notificar al operador.

Por eso la retirada necesita su propio cierre. El emisor anuncia la retirada, el receptor la procesa y la RIB elimina el objeto; aun así, la política o la tabla de hardware puede conservar efecto. Ausencia del anuncio no demuestra ausencia del filtro.

Dos velocidades, una sola responsabilidad

RFC 4760 permite distribuir familias a escala y los reflectors multiplican el alcance. Extended Communities llevan acciones. BGP es rápido porque no espera la programación de cada destino.

La revisión propone complementar esa velocidad con consultas de instalación mediante NETCONF o RESTCONF. RFC 6241 y RFC 8040 ofrecen intercambios request/response, pero no inventan por sí solos un modelo común de recibo FSv2. Una respuesta puede confirmar que se aceptó una petición o cambió un datastore sin demostrar una entrada de hardware ni el tratamiento de un paquete.

La arquitectura útil tiene dos ritmos: BGP abre una intervención limitada; una comprobación más lenta confirma, nodo por nodo, la regla efectiva, sus contadores, su caducidad y su retirada.

Qué debe contener el recibo

Conservar versión e identificadores; autoridad y lista de objetivos; NLRI, User Order, DFC y flags; comunidades de acción; entradas de validación y excepciones; tiempos de anuncio y recepción; capacidades por nodo; elementos desconocidos u omitidos; decisión local del DFC; orden combinado FSv1/FSv2; identidades de tablas de software y hardware; contadores o muestras; expiración, retirada y eliminación observada; y la decisión de continuar, acotar o revertir.

La recepción demuestra transporte. La validación demuestra conformidad con reglas locales. La tabla demuestra programación. Los contadores demuestran encuentro con tráfico. La recuperación exige otra observación.

La prioridad del código en ejecución consiste precisamente en no confundir esos recibos.

Fuentes