Resumen

  • RFC 9573 sustituye espacios de etiquetas por emisor por un bloque común de dominio o unos pocos espacios contextuales compartidos.
  • La reducción depende de que todos los PE y puntos de segmentación admitan el procedimiento y conozcan la misma asignación, condiciones cuya garantía queda fuera del RFC.
  • La operación necesita recibos separados para autoridad, época, reserva, selección de tabla, instalación, coherencia de rutas y entrega real del tráfico.

La tabla exterior acertó; la interior estaba atrasada

Un paquete llega con dos etiquetas. La exterior selecciona correctamente el espacio contextual número tres. La interior vale 2088. En ocho PE, 2088 conduce al dominio de difusión nuevo. En el noveno, una actualización fallida conserva la asociación anterior. El primer salto de interpretación es exacto y el segundo es falso.

Esa escena explica por qué RFC 9573 no puede leerse sólo como una mejora de escala. El modelo anterior interpretaba las etiquetas asignadas por el origen dentro del contexto de cada PE emisor. En el ejemplo del RFC, 1.001 PE con 1.000 VPN o dominios cada uno obligan a cada receptor a estar preparado para un millón de significados distribuidos en mil espacios.

Una entidad central puede asignar un mismo número a un VPN, BD o segmento Ethernet. El receptor conserva muchas menos entradas. A cambio, el significado ya no está separado por el origen: depende de que una asignación externa se haya instalado igual en toda la población relevante.

«Común» describe el acuerdo, no lo verifica

El documento exige que todos los PE y puntos de segmentación soporten el procedimiento. Acto seguido deja fuera de alcance cómo se garantiza ese soporte. También deja fuera de alcance el método por el que se asignan los labels y se informa a cada PE miembro.

Por eso el DCB —el bloque común de dominio— debe tratarse como una zona gobernada. Hace falta saber qué nodos pertenecen al dominio, qué rango reservan, quién asigna cada valor y qué revisión consideran vigente. Dos dispositivos pueden anunciar el mismo bit DCB y, aun así, diferir en la tabla local.

La ruta comunica una intención tipada. No es un recibo de la escritura en hardware. Tampoco acredita que un equipo ausente, reiniciado o aislado recibió la misma convención.

La indirection conserva dos historias

Si el bloque común por defecto no es suficientemente grande, RFC 9573 permite que una etiqueta del DCB identifique un espacio contextual compartido. Debajo viaja la etiqueta de servicio. El receptor usa la primera para escoger una tabla y la segunda para escoger una entrada dentro de ella.

La Extended Community de Context-Specific Label Space ID hace explícita esa selección. Sin embargo, la operación debe conservar dos historias: cuándo se creó o cambió la tabla y cuándo se asignó el servicio dentro de ella. Un selector correcto no sanea una entrada interna obsoleta.

La comparación útil abarca el estado deseado del controlador, la configuración aceptada, la tabla MPLS por defecto, la tabla contextual y una observación de datos. Resumir todo como «BGP convergió» elimina precisamente la evidencia necesaria para investigar una discrepancia.

En una frontera, dos flujos dejan de compartir destino

La segmentación de túneles introduce un caso que impide usar siempre una sola etiqueta de VPN. Dos flujos pueden viajar juntos por T1 en una región y separarse hacia T2 y T3 en la siguiente. El punto de segmentación necesita distinguirlos sin realizar necesariamente búsquedas IP o MAC en una VRF.

El RFC asigna bloques disjuntos a los PE dentro de espacios contextuales comunes. Cada PE toma de su propio bloque las etiquetas de PMSI segmentado. La independencia local funciona sólo mientras la propiedad de los bloques siga siendo exclusiva y visible.

La alternativa usa búsquedas (C-S,C-G) en VRF. Reduce etiquetas por PMSI, pero aumenta rutas de flujo y requisitos de estado en el punto de segmentación. No hay desaparición de estado: hay una decisión sobre dónde residirá y qué sistema responderá por él.

La contradicción tiene una salida normativa

Una ruta no puede llevar simultáneamente el DCB flag y el identificador de espacio contextual. Si aparecen juntos, se trata como retirada. Si no aparece ninguno, rigen las reglas antiguas de etiqueta asignada por el PE origen.

Las rutas que comparten un túnel también deben coincidir en el régimen de interpretación. La mezcla obliga al receptor a tratarlas como retiradas porque no podría decidir de forma segura qué tabla usar para la siguiente etiqueta.

Es un límite sano: no improvisar ante una semántica ambigua. Pero el recibo de retirada pertenece al plano de control. Todavía se debe comprobar que las entradas anteriores desaparecieron, que el tráfico dejó de circular y que la futura reutilización del número no alcanzará a nodos retrasados.

El registro fija la gramática

IANA registra el bit DCB, el subtipo de la Extended Community y los tipos de identificador. Eso evita que dos implementaciones inventen códigos distintos para la misma estructura. No demuestra que una implementación exista, que una función esté activada o que una asignación sea correcta.

RFC 9573 tampoco afirma un nuevo riesgo de seguridad respecto de sus bases. La frontera descrita aquí no debe convertirse en una acusación de vulnerabilidad sin evidencia. Es un problema de autoridad y comprobación: quién define el significado compartido, cómo se prueba su distribución y dónde termina la afirmación del protocolo.

Sources

Fuentes