Resumen

  • RFC 9835 guarda en el AC de red la referencia del AC presentado en la capa de servicio. La relación permite rastrear una solicitud hasta su objeto de implementación, no certificar continuidad, reenvío o entrega.
  • El nombre de red tiene alcance de nodo. La configuración efectiva depende de perfiles heredados, excepciones locales y relaciones padre-hijo; el estado administrativo no sustituye al operativo.
  • La prueba termina fuera del inventario: objetivo correcto, configuración aplicada, estado observado, OAM con alcance definido, salud del servicio completo y tráfico útil para el cliente.

El pedido quedó cerrado antes de que pasara el primer paquete

Un cliente pide conectividad para una sede. El portal asigna una referencia y el orquestador crea un circuito de acceso en un PE. Inventario y sistema comercial coinciden. Esa coincidencia es valiosa: evita confundir el pedido con otro. Pero no demuestra que el bearer esté disponible, que el VLAN sea correcto, que el enrutamiento funcione o que las demás sedes del VPN estén alcanzables.

RFC 9835, identificado también por su ficha oficial, normaliza el modelo de red ietf-ac-ntw. La norma permite aprovisionar circuitos de acceso antes o durante el servicio y conservar la referencia del objeto que la capa de servicio expone al cliente.

La referencia responde una pregunta de identidad operacional: ¿qué AC de red pretende realizar esta solicitud? No responde, por sí sola, qué ejecutaron los equipos ni qué recibió el cliente.

El bearer sostiene al AC, pero no lo reemplaza

RFC 9833 distingue el enlace físico o lógico —el bearer— de la configuración de circuito de acceso montada sobre él. Varios AC pueden compartir un bearer. Un AC puede alcanzar varios SAP pares y un SAP puede terminar varios AC.

Esta topología impide la inferencia cómoda. Un bearer sano puede alojar un AC mal configurado. Un bearer roto puede afectar muchos AC. La referencia del bearer indica el lugar de enlace y ayuda a medir el impacto, pero no acredita que el servicio pedido esté activo.

RFC 9834 modela bearers y AC como servicios solicitables. RFC 9835 describe el lado de red. RFC 9836 agrega las referencias que unen esos AC con los modelos de servicio y red L2VPN y L3VPN. La separación no es un defecto que deba ocultarse. Es el mapa de las autoridades que participan.

Un registro durable necesita más que un “circuit-id”: referencia de servicio, red, nodo, nombre local del AC, SAP, bearer y época de la asignación. Si la implementación migra, la referencia externa puede permanecer, pero las correspondencias vieja y nueva no deben confundirse.

svc-ref facilita la correlación, no emite un veredicto

RFC 9835 explica que ietf-ac-ntw aprovecha la referencia de servicio para correlacionar la solicitud con el AC realmente aprovisionado en la red. El nombre de ese AC es único dentro de un nodo, no en toda la red. Además, usar la misma convención de nombres en servicio y red es una decisión del despliegue.

Por eso, ac-17 no es una identidad global. Puede existir en varios nodos. Una comparación de cadenas sin red y nodo puede unir historias ajenas. El recibo correcto guarda el tuple completo, el orquestador que decidió el enlace y su vigencia temporal.

RFC 8969 separa modelos de servicio del cliente, modelos de red y modelos de dispositivo. Traducir entre ellos requiere política, información y un actor. Un esquema común limita ambigüedades; no convierte la traducción en verdad física.

La configuración efectiva no vive en un solo lugar

RFC 9835 permite perfiles de red que varios AC heredan. Si un dato se redefine en el AC, la valor local tiene precedencia. Para reconstruir un fallo no basta guardar el nombre del perfil ni únicamente las excepciones. Hacen falta la versión heredada, los valores reemplazados y una huella de la configuración resultante.

El tiempo importa. Si un perfil cambia mañana, no debe alterar la explicación del circuito que existía ayer. Cada aplicación necesita una época y un recibo de destino.

RFC 9836 también establece prioridad cuando una referencia AC y datos VPN incluidos directamente se superponen: la información referenciada prevalece. Es una regla de resolución de intención, no una prueba de aplicación atómica, interpretación uniforme ni reversión completa.

RFC 8342 aporta la arquitectura de almacenes que diferencia intención y estado operacional. RFC 8345 aporta el modelo de topología que RFC 9835 amplía. La pregunta responsable no es “¿existe el objeto?”, sino “¿qué se pidió, qué quedó efectivo y qué se observa?”.

Borrar el padre es ejercer poder sobre los hijos

El modelo admite un AC padre con propiedades comunes y AC hijos con información específica para determinados SAP pares. Los hijos heredan. Al eliminar el padre, RFC 9835 exige eliminar todos los hijos.

La norma evita huérfanos lógicos, pero la cascada amplía el impacto de una acción. No demuestra que un controlador haya identificado todos los dependientes, retirado el estado de equipos en orden, protegido servicios ajenos, detenido cobros o preservado una vuelta atrás.

Antes de borrar, el operador debería congelar un conjunto de impacto: padre, hijos, SAP, servicios, bearer, perfiles efectivos y estado observado. Después debería contrastarlo con configuración real y pruebas de tráfico. Una fila ausente en el modelo no prueba que ya no queden rutas, filtros o clientes afectados.

La discrepancia de estados es información

RFC 9835 conserva estado administrativo y operativo. Su discrepancia puede activar una investigación. RFC 9833 incluye estados de espera de validación, espera de procesamiento, prohibición administrativa y rechazo. Describen el flujo de trabajo, no el plano de datos.

Un pedido aprobado puede no haberse activado. Un AC configurado puede estar caído. Un interfaz “up” puede transportar el VLAN incorrecto. Un acceso local sano puede formar parte de un VPN incompleto.

RFC 9408 define el SAP como referencia del lado proveedor y aclara que el estado del servicio en un SAP no equivale al estado global de un servicio que conecta varios puntos. RFC 9181, RFC 9182 y RFC 9291 aportan tipos y modelos VPN; RFC 9543 sitúa servicios de slice en un marco todavía más amplio. Ninguno autoriza a un estado local a hablar por todo el resultado.

La cadena útil separa solicitud, aceptación, referencia, correspondencia a red/nodo/SAP/AC, resolución de herencia, envío a objetivos, estado observado, OAM limitado, estado de extremo a extremo y canario del cliente. No es obligatorio usar nueve bases de datos; sí impedir que un recibo inferior adopte el significado del siguiente.

Las fuentes no establecen un despliegue, proveedor, producto, incidente, adopción, ahorro ni SLA medido. La propuesta de conservar esta cadena es análisis operativo, no un requisito nuevo del RFC.

El acceso a los datos modifica la superficie de riesgo

RFC 9835 advierte que lecturas no autorizadas pueden revelar identidades peer-sap-id. Sus datos escribibles pueden alterar enrutamiento, filtros, cifrado, claves y vínculos de servicio. Quien edita la correspondencia entre pedido y AC puede cambiar la realidad que luego describe el inventario.

Conviene separar la facultad de crear la intención comercial, traducirla a red, escribir dispositivos y observar el resultado. El log debe retener actor autenticado, alcance, valores anterior y nuevo. El éxito de una llamada API no sustituye ese mandato.

RFC 9835 es valioso porque hace visible la costura entre promesa y ejecución. La automatización es responsable cuando la referencia conduce a observaciones independientes y al resultado del cliente. Si la referencia cierra el caso, sólo se ha automatizado la apariencia de cumplimiento.

Fuentes