Resumen

  • Las RFC 9833–9836 definen vistas distintas para el portador físico o lógico, el circuito de acceso solicitado por el cliente, el AC de red del proveedor y las referencias que los enlazan con VPN de capa 2 o 3.
  • Una petición aprobada puede seguir en awaiting-processing, y los nombres del AC de servicio y del AC de red pueden ser diferentes. Aceptación y coincidencia nominal no demuestran realización.
  • La evidencia continúa con el mapeo de red, la selección de PE/SAP, el enlace VPN, la configuración prevista y aplicada, el estado operativo, OAM y tráfico. Cada paso responde a una pregunta distinta.

El sistema comercial había registrado el circuito. El sistema de red todavía no tenía el objeto que debía hacerlo real.

Esa divergencia no basta para afirmar engaño, caída ni incumplimiento. Es una separación deliberada en las RFC 9833, RFC 9834, RFC 9835 y RFC 9836. Publicadas en septiembre de 2025 como normas propuestas en la vía Standards Track, distribuyen el circuito de acceso entre varios modelos YANG conectados. Así evitan que el nombre y el estado de una capa se apropien de la autoridad de otra.

Las fichas de RFC 9833, RFC 9834, RFC 9835 y RFC 9836 acreditan consenso de la IETF y aprobación del IESG. No acreditan que un proveedor concreto implemente los módulos, que haya aceptado un pedido ni que un paquete haya circulado. Publicar una norma y operar un servicio son recibos diferentes.

El portador y el circuito no son sinónimos

El bearer es el enlace cableado o inalámbrico subyacente. El attachment circuit es la disposición establecida sobre él para que una terminación del cliente intercambie datos con la red del proveedor. Un bearer puede transportar varios AC; un AC puede asociarse a varios equipos cliente o SAP pares; un mismo equipo cliente puede terminar varios AC.

Por eso, “portador disponible” no significa “servicio correcto activo”. Tampoco una baja de servicio autoriza a retirar todo el recurso compartido. Si la plataforma reduce esa cardinalidad a un único indicador, perderá precisamente la información necesaria para limitar el alcance de una acción automática.

La RFC 9834 permite que el proveedor asigne una referencia de bearer, que el cliente recupera y usa después al pedir el AC. El proveedor puede aceptar o rechazar identificadores aportados por el cliente. El identificador de AC solo tiene que ser único dentro del dominio del proveedor: es una referencia con ámbito, no un nombre universal. Deben conservarse su emisor, su dominio y su resolución vigente.

El modelo del cliente describe el deseo, no el taller

La RFC 8309 define el modelo de servicio al cliente como una descripción del servicio pedido o experimentado, no de la ingeniería interna que lo realiza. La RFC 9834 mantiene esa frontera. El cliente expresa requisitos; el proveedor decide nodos PE, SAP, interfaces, topología y tecnología.

Ese reparto permite que una solicitud común viaje entre redes internamente distintas. También impide usar el objeto de cliente como prueba de una asignación PE/interfaz que el modelo oculta deliberadamente. La respuesta al pedido solo puede probar su propio ámbito: solicitante autenticado, permiso, referencia de bearer o SAP par, identidad del AC de servicio, parámetros, validación y estado administrativo.

La RFC 9833 incorpora estados como awaiting-validation, awaiting-processing, admin-prohibited y rejected. Una solicitud puede estar aprobada y validada, pero seguir esperando trabajo antes de activarse. Pintar awaiting-processing como “activo” fabrica una conclusión que la fuente se niega a dar.

La red necesita un objeto distinto

La RFC 9835 define ietf-ac-ntw, donde el proveedor relaciona la referencia de servicio con el AC de red y mantiene el detalle de PE y SAP. Aquí empieza la materialización de la intención en recursos concretos.

El propio texto advierte que usar o no la misma convención de nombres en servicio y red depende del despliegue. Los identificadores podrían coincidir, pero no cabe presumirlo. La prueba es la arista que los referencia. Una unión por igualdad de texto puede ligar telemetría al pedido equivocado tras una migración, un renombrado o una reutilización.

La fila de red tampoco equivale a configuración aplicada. La RFC 8969 sitúa los modelos de red entre los modelos de servicio y los parámetros de dispositivo, y exige devolver estado operativo y estadísticas. El objeto registra la intención del orquestador; la respuesta del plano inferior determina cuánto llegó a ejecutarse.

El glue identifica la relación, no el resultado

La RFC 9836 introduce ietf-ac-glue para vincular los AC con los modelos VPN. Extiende el modelo de servicio L3VPN de la RFC 8299, el modelo de servicio L2VPN de la RFC 8466 y el modelo de red L3VPN de la RFC 9181. Las RFC 8345 y RFC 9543 aportan contexto de topología y garantía de servicio.

Una referencia glue demuestra qué AC se asocia en el modelo con qué VPN. No demuestra reserva de recursos, aplicación en equipos, alcance, reenvío ni SLA. Si varios servicios comparten AC, tampoco concede a uno autoridad sobre el ciclo de vida de los demás.

Un fallo puede esconderse en un grafo lleno de objetos válidos: el AC de servicio se mapea al AC de red A, pero el glue de la VPN apunta al B. Nada falta, los identificadores tienen formato correcto y, sin embargo, la relación operativa es falsa. Un control de mera presencia lo aprobará.

Intención, aplicación y operación necesitan recibos propios

La RFC 8342 distingue valores configurados, configuración prevista y estado operativo. Retardos, hardware, protocolos y dependencias pueden separarlos. Comparar <intended> con <operational> permite ver qué parte de la intención está en uso.

La cadena completa autentica y autoriza al principal, resuelve el bearer, acepta el AC de servicio, lo enlaza con el AC de red, selecciona PE/SAP/interfaz, asocia la VPN correcta, genera configuración prevista, observa la aplicada y el estado, y mide aparte OAM, alcance, tráfico y resultado de servicio.

La RFC 7950 aporta YANG, pero no obliga a una arquitectura interna única. La RFC 9408 ofrece un marco de seguridad para módulos YANG. Ninguna de estas fuentes prueba una filtración o explotación concreta; sí obliga a asociar la autorización al objeto y a la capa correctos.

La idea de Heng Lu de especificación inicial mínima y decisión futura localizada encaja exactamente: compartir semántica determinista sin centralizar la topología interna. La primacía del código en ejecución pregunta si esas referencias sobreviven en producción. Y la realidad, no la defensa de una causa, limita la conclusión: las cuatro RFC dibujan una buena cadena de control, pero no certifican ningún circuito vivo.

Fuentes