Resumen

  • La versión 08, publicada el 28 de septiembre, es un Internet-Draft activo del grupo IDR. No es una RFC ni una asignación definitiva de códigos.
  • La versión 07 agrupaba el filtrado IP básico en la familia propuesta 256 y llamaba 60 al componente de prefijo de destino IP. La 08 propone familias distintas para IPv4 básico (1000) e IPv6 básico (1100); el prefijo de destino IPv4 pasa a ser el componente 1000 dentro de su familia.
  • La diferencia entre transportar un NLRI y entender su semántica queda expresamente contemplada en el propio borrador para despliegues parciales.

La unidad de lectura es una pareja, no una cifra

RFC 8955 documenta el FlowSpec original para IPv4. El proyecto de la segunda versión propone otra estructura: familias de filtros codificadas en TLV, componentes dentro de cada familia y reglas de ordenación. La revisión de septiembre ya no utiliza una única lista básica indiferenciada. Además de dividir IPv4 e IPv6, distingue conjuntos para Queue Pair, CAT y Routing Augment. Una etiqueta legible por una persona puede conservar su apariencia mientras el identificador que la máquina procesa cambia de contexto.

Por eso una prueba preparada para la pareja familia 256/componente 60 no acredita automáticamente el tratamiento de familia 1000/componente 1000. No se trata de anunciar una incompatibilidad observada: no hay aquí resultados públicos de una prueba de interoperabilidad entre esas dos revisiones. Se trata de no borrar la versión de un contrato todavía móvil. La propuesta exige un orden estricto de los TLV y prohíbe duplicados. Antes de debatir la acción sobre el tráfico, el receptor debe poder delimitar y leer la regla que recibió.

La sección de IANA aún pide crear registros y asignar un AFI y dos SAFI; varios valores siguen como TBD. Los números impresos en las tablas son parte de un borrador. Presentarlos como asignaciones consumadas confundiría publicación del texto con cierre del proceso.

Reenvío de control no significa filtrado aplicado

El apartado sobre despliegues parciales distingue a los nodos que comprueban sintaxis de los que conocen el significado de una familia nueva. La sección de validación permite propagar un NLRI bien formado aunque un nodo no entienda un componente, según la configuración; advierte también que una incorrección semántica puede llegar al nodo que sí lo interpreta. El proyecto separa, además, filtros obligatorios y opcionales y explica cómo una regla localmente inválida puede afectar a una cadena dependiente.

La noticia no es que una red haya fallado. Es que hay varios recibos posibles para una misma política: ruta recibida, ruta reenviada, familia reconocida, filtro instalado y paquetes efectivamente tratados. Ninguno sustituye por sí solo a los demás. Esa distinción vuelve auditable una decisión de adopción durante la transición de una gramática de borrador a otra.

Fuentes