Resumen

  • RFC 7212 permite que un extremo MPLS anuncie capacidades, parámetros de configuración e información específica de aplicaciones mediante G-ACh; no convierte al emisor en autoridad de configuración del receptor.
  • El receptor conserva el control mediante la habilitación por canal, la autorización local de aplicaciones, las reglas de cada aplicación, la vida útil declarada y la autenticación con comprobación temporal.
  • La automatización segura necesita una cadena visible: qué llegó, cómo se autenticó, hasta cuándo vale, qué política local lo consumió y por qué cambió un valor.

Un anuncio comunica un hecho, no una orden

GAP resuelve un problema práctico de las redes de transporte. El extremo de un LSP, pseudowire o sección puede necesitar informar a su par de las capacidades que admite, los parámetros que usa o los datos que una aplicación debe conocer. En un entorno MPLS-TP sin IP pueden faltar los mecanismos habituales de descubrimiento. Un canal de anuncios independiente de la capa de enlace reduce la configuración estática frágil y permite detectar antes las incoherencias.

La frontera de liderazgo está en la palabra «anuncio». RFC 7212 define un modo unidireccional sencillo: un emisor configurado transmite bloques de datos tipados por aplicación. El receptor puede validar o ajustar su configuración, pero los papeles administrativos no se fusionan. La transmisión y la recepción se habilitan por canal bajo control del operador. Todas las aplicaciones GAP están desactivadas por defecto. Los datos recibidos solo se ofrecen a aplicaciones locales que los necesitan y están autorizadas a verlos.

La distribución del poder queda clara. El emisor controla lo que afirma sobre sí mismo. El operador receptor decide si GAP funciona, qué aplicación puede leer el dato y qué puede hacer con él. La especificación de la aplicación determina el significado de sus TLV. La llegada de un paquete no demuestra ninguno de esos permisos.

Un mecanismo concreto de control

Imaginemos dos nodos MPLS-TP adyacentes en una sección Ethernet sin reenvío IP. El nodo A anuncia su dirección MAC de origen y el tamaño máximo de trama mediante la aplicación Ethernet Interface Parameters de RFC 7213. El nodo B aprende la dirección y compara el tamaño anunciado con su mínimo local.

Es una evidencia valiosa, pero no una orden remota para apagar el enlace. RFC 7213 deja la consecuencia a la política configurada: el operador puede bajar el enlace cuando hay incompatibilidad o mantenerlo y usar OAM para comprobar el tamaño efectivo. El mismo hecho recibido admite, por tanto, decisiones legítimas distintas según la política local.

El operador obtiene una visión verificable del estado del par, una vía para sustituir supuestos estáticos obsoletos y una traza de diagnóstico cuando los extremos discrepan. RFC 7213 recomienda enviar pronto el anuncio correspondiente tras una reconfiguración, un reinicio o una desconexión detectada para volver a inicializar el estado del enlace. Las aplicaciones comparten un transporte que no depende de un protocolo de descubrimiento concreto. Ningún beneficio exige ceder la autoridad del cambio local.

Vigencia, identidad y significado son comprobaciones distintas

Cada bloque de aplicación incluye una vida útil. Los datos estáticos solo se conservan durante ese plazo. Un valor cero los marca inmediatamente como expirados; un bloque vacío puede hacer expirar los datos anteriores de la aplicación. Tras un reinicio deben descartarse los datos retenidos del par. Así se evita que una observación antigua se presente como autoridad actual.

La autenticación responde a otra pregunta. RFC 7212 define autenticación de mensajes y marcas de tiempo para limitar la repetición. Los identificadores de clave se asocian con parámetros criptográficos mediante configuración explícita del operador o un intercambio separado. Autenticidad, vigencia y autorización semántica siguen separadas. Un MAC válido acredita que una clave admitida protegió el mensaje; no decide si una aplicación debe reescribir un parámetro ni prolonga un dato vencido.

Si el receptor no puede interpretar una aplicación, puede conservar sus bytes durante la vida anunciada porque quizá sean útiles al operador. Conservar evidencia no equivale a ejecutarla. El sistema puede admitir que desconoce el significado sin inventar una acción.

El coste operativo acompaña a la autoridad

GAP deja deliberadamente varias cargas a aplicaciones y operadores. El emisor elige la frecuencia. La aplicación fragmenta la información que no cabe, porque GAP no ofrece fragmentación ni reensamblado. Aplicación y operador deben evitar congestionar el enlace. Las claves, los relojes, la tolerancia de repetición, la caducidad, la limpieza tras reinicios y la trazabilidad necesitan responsables concretos.

RFC 7212 también exige que los datos recibidos sean inspeccionables. Si una información entrante cambia la configuración local, debe quedar claro por qué. Ese es el control decisivo: la automatización es gobernable cuando un recibo permite reconstruir el paso de una observación autenticada a una regla local y a un cambio. Sin esa prueba, la comodidad convierte en silencio la declaración del par en autoridad inexplicada.

Fuentes