Resumen

  • RFC 9252 permitía combinar por OR el argumento de Route Type 1 y el SID End.DT2M de Route Type 3; RFC 9819 aclara que esa operación exige estructuras idénticas.
  • Cuando las estructuras difieren, el ingress PE toma Arg.FE2 de Ethernet A-D per ES y lo inserta en el offset declarado por el SID LOC:FUNC de Inclusive Multicast.
  • Superar AL y el resto de reglas de composición no demuestra selección local, programación, ejecución del split horizon ni entrega sin bucles o duplicados.

La interoperabilidad suele fallar en las suposiciones que nadie registra. Dos equipos pueden mostrar los mismos bytes, aceptar los mismos atributos y aun así construir direcciones distintas porque no comparten la interpretación de dónde termina Function y dónde comienza Argument.

Ese fue el punto débil que documentó RFC 9819. RFC 9252 había descrito una operación OR entre dos anuncios EVPN: Ethernet A-D per ES transporta el ESI Filtering Argument; Inclusive Multicast Ethernet Tag transporta el End.DT2M SID. La fórmula era válida dentro de una estructura uniforme. Las pruebas de implementación e interoperabilidad mostraron que esa uniformidad no podía darse por universal.

El cambio no inventa otro identificador. Obliga a respetar la autoridad estructural del SID que contiene LOC:FUNC. En lugar de mezclar mapas de bits anónimos, el origen SR inserta el argumento en la posición indicada por la estructura del Service SID.

El argumento no hereda la identidad de la ruta

RFC 8986 define End.DT2M como una conducta de desencapsulado y flooding en una tabla L2. Arg.FE2 señala una asignación local hacia un ESI para excluir interfaces durante el flooding. La asignación pertenece al nodo que instancia el endpoint behavior.

Por eso un valor aaaa no significa lo mismo fuera de su asociación. Debe viajar con tamaño, behavior y vínculo hacia los SIDs aplicables. El endpoint propietario de LOC:FUNC anuncia además LBL, LNL, FL y AL. La suma de las tres primeras longitudes sitúa el argumento; AL expresa cuánto espacio acepta.

Route Type 3 contiene el LOC:FUNC End.DT2M del dominio de broadcast. Route Type 1 contiene el argumento del Ethernet Segment. Si el filtrado ESI no se utiliza, Type 3 anuncia AL=0 y el receptor ignora el SID y la estructura de Type 1. Si se utiliza, el AL de Type 3 debe coincidir con el AL del anuncio A-D correspondiente.

La igualdad no equivale a identidad estructural. El ejemplo de varios bridge domains en RFC 9819 usa el mismo argumento de 16 bits con un SID cuyo FL es 32 y otro cuyo FL es 16. El argumento queda en posiciones distintas. Este ejemplo es la razón para dejar de usar OR cuando los layouts no son iguales.

Cuatro estados merecen cuatro etiquetas

Con AL=0 en Type 3, se construye LOC:FUNC y se ponen a cero los bits posteriores. El argumento de Type 1 no participa.

Con AL distinto de cero, el ingress busca el Ethernet A-D per ES coincidente y verifica End.DT2M. Si no aparece o trae AL=0, no hay argumento utilizable. Puede formarse LOC:FUNC-only, pero la ausencia debe registrarse si el filtrado era esperado.

Si ambos AL son no nulos pero diferentes, existe un error de configuración. El RFC exige no reenviar BUM desde ese Ethernet Segment por el riesgo de bucle y recomienda registrar el error.

Solo con AL iguales y no nulos se toma el argumento de Type 1, se inserta según LBL + LNL + FL de Type 3 y se ponen a cero los bits sobrantes. Un panel que reduce estas cuatro ramas a «ruta aceptada» elimina la acción más importante: ignorar, degradar, bloquear o construir.

La asociación vive dentro de EVPN

Las coordenadas de RFC 7432 ayudan a evitar una unión falsa: Route Distinguisher, Route Target, Ethernet Tag, ESI, originador, next hop y withdrawals. La pareja debe pertenecer al EVI, broadcast domain y Ethernet Segment correctos. También debe sobrevivir una pregunta temporal: ¿ambas rutas representan el mismo estado después del último retiro?

La presencia en RIB no garantiza que una caché local, un controlador o la programación de hardware haya consumido la misma generación. Conviene registrar los dos path identifiers, su selección y la hora. Cuando el diseño usa local bias según RFC 8365, el argumento ESI no debe fusionarse.

RFC 9819 admite combinaciones de flavors comprimidos y no comprimidos de RFC 9800 si las comprobaciones de AL se cumplen. Eso amplía la compatibilidad sin declarar equivalentes los behaviors. Tampoco modifica la Transposition Scheme: offset, longitud transpuesta y tamaño del campo MPLS continúan siendo parte de la validación de RFC 9252.

El dataplane necesita otro testigo

Un SID final puede estar bien formado y no ser usado. La política local puede rechazar la ruta, elegir otra, carecer de la función nueva o seguir aplicando el OR anterior. El ingress debe probar qué ruta eligió y qué dirección programó. El egress debe probar que el local SID existe con el flavor correcto, la tabla L2 prevista y la asociación actual de Arg.FE2.

Después llega la observación de paquetes: dirección destino, desencapsulado, interfaces excluidas, drops, duplicados y bucles. Después llega la entrega: receptores previstos, copias prohibidas y resultado de la carga. Ningún eslabón se sustituye por el anterior.

La cadena útil es: identidad y frescura de anuncios; behavior y estructura; asociación; construcción exacta; aceptación local; estado programado; ejecución del paquete; resultado del servicio. RFC 9819 fortalece los eslabones de estructura y construcción. No afirma haber cerrado los demás.

El alcance se mantiene separado del artículo de RFC 10018 sobre árboles P2MP y entrega por hoja, de RFC 9830 sobre candidatos SR Policy, de RFC 9863 sobre Color PCEP y de RFC 10039 sobre D-PATH interdominio. Aquí la pregunta es anterior: ¿los bits que llegaron pueden representar el SID de servicio pretendido sin inventar una estructura común?

La propuesta de especificación inicial mínima de Lu Heng sirve como método editorial: conservar como común solo lo determinista y verificable. Running-Code Primacy impide confundir publicación con adopción, y Reality Layers evita tomar una declaración simbólica por un efecto físico. No son requisitos atribuidos al IETF.

Fuentes