Resumen

  • SIMAP define recorridos descendentes desde servicios hasta recursos lógicos y físicos, y recorridos ascendentes desde un recurso hasta los servicios que dependen de él.
  • La respuesta demuestra lo que un servidor expuso a un cliente bajo una vista y una política de acceso; la completitud, el tiempo, la causa, la autorización, la ejecución y el resultado necesitan pruebas separadas.

Una operación de impacto empieza con una pregunta sencilla: si falla este enlace, ¿qué servicios quedan expuestos? La respuesta difícil no es una lista, sino una cadena. Hay que enlazar el producto que reconoce el cliente con sus componentes, los nodos y enlaces lógicos, las capas inferiores y los equipos físicos. Después conviene recorrer el mismo camino en sentido contrario para comprobar que el recurso seleccionado lleva de vuelta al conjunto de servicios esperado.

La Service & Infrastructure Map del IETF pretende convertir esa cadena en un grafo navegable. El avance es importante. También crea un riesgo semántico: cuanto más limpia es la respuesta, más fácil resulta confundirla con una fotografía completa de la red.

La fuente es la revisión 13 de draft-ietf-nmop-simap-concept, fechada el 4 de septiembre de 2026. El Datatracker la registra como Internet-Draft activo del grupo NMOP, con destino informativo. El historial muestra que está en IETF Last Call hasta el 26 de septiembre. No es un RFC final y su contenido todavía puede cambiar.

El grafo y sus fuentes no son la misma cosa

El núcleo de SIMAP usa redes, nodos, enlaces y puntos de terminación. Las relaciones de soporte conectan entidades dentro de una capa y entre capas. En el recorrido servicio-recurso, el cliente baja desde la topología del servicio hasta los recursos lógicos y físicos. En el recorrido recurso-servicio, parte de un elemento físico, de capa 2 o de capa 3 y sube hacia los servicios, enlaces, nodos y terminaciones que se apoyan en él.

RFC 8345 ya define en YANG redes de soporte, nodos de soporte, enlaces de soporte y puntos de terminación de soporte. SIMAP amplía el marco para unir el plano del servicio con la infraestructura y con otros modelos. Sin embargo, la capacidad, el estado, el rendimiento, el inventario, la configuración y la observabilidad pueden permanecer fuera del núcleo. La mapa ofrece referencias a esos sistemas; no absorbe automáticamente su autoridad.

Una referencia externa debe conservar tres preguntas. ¿Es realmente el mismo objeto? ¿Fue observado en el mismo momento? ¿Representa un hecho medido, una intención o una inferencia? Una unión por nombre puede combinar un equipo del inventario del lunes, un síntoma de assurance del martes y una relación topológica del miércoles. El grafo resultante parece preciso, aunque nunca existió como estado simultáneo.

La visibilidad depende del permiso

El borrador indica que una aplicación solo puede recuperar lo que está autorizada a ver. El servidor puede ocultar capas o entregar una abstracción en lugar de la topología nativa por motivos de seguridad, administración o negocio. Una respuesta parcial puede ser exactamente la respuesta correcta para ese cliente.

Por ello, lo que no aparece no puede declararse inexistente. Un nodo abstracto puede resumir varios equipos. Un enlace puede ocultar rutas físicas con destinos de fallo distintos. Un proveedor puede exponer la dependencia necesaria para operar un servicio sin revelar la planta interna. La política de acceso no degrada la calidad del dato; define su alcance.

También hay dos ejes distintos. Navegar entre capas explica, por ejemplo, qué camino de capa 2 soporta un enlace de capa 3. Navegar entre niveles de abstracción explica qué nodos nativos se condensaron en un único nodo abstracto. Un recibo de consulta que solo dice “capa 3” deja sin responder la granularidad y el perímetro de la vista.

Una topología live sigue necesitando fecha

La revisión 13 llama live a la última instantánea de la red real. Exige descubrimiento y sincronización para ofrecer topologías actualizadas. Son requisitos de diseño para las implementaciones; no son una garantía automática de que una respuesta concreta acabara de sincronizarse.

El mismo marco admite instantáneas, topologías potenciales, topologías pretendidas y elementos pasivos. La topología pretendida expresa el diseño deseado y puede omitir saltos o dispositivos intermedios. La parte pasiva puede registrar infraestructura que los protocolos de red no descubren. El estado y el historial pueden residir en la propia SIMAP o en un modelo externo.

Antes de usar una relación para decidir, hay que identificar la instancia, el tipo de vista, la fuente, la hora de observación y la condición de sincronización. “Live” sin esos datos es una etiqueta, no una prueba de frescura.

Exposición no significa causa

Si el recorrido ascendente encuentra cuatro servicios, la conclusión defensible es que esos servicios estaban modelados como dependientes del recurso bajo la vista consultada. No significa que el recurso causara cuatro fallos. Puede ser un respaldo, participar en balanceo, aparecer en una relación antigua o haber cambiado después de la instantánea. Uno de los servicios puede haber fallado por otra causa.

La causalidad exige ordenar los hechos: cambio de estado del recurso, degradación compatible del tráfico o del servicio, exclusión razonable de alternativas y recuperación después de una intervención. SIMAP puede organizar los enlaces entre pruebas. No puede transformar la cercanía del grafo en causalidad.

Escribir el modelo no configura la red

El texto separa otra frontera con claridad. SIMAP puede ofrecer operaciones de lectura y escritura, pero una escritura en la topología no está destinada a modificar directamente la red en producción. Las escrituras sirven a escenarios hipotéticos y a topologías pretendidas o pasivas; la actuación real pasa por las operaciones normales del controlador.

Por tanto, un sistema automático necesita registros distintos para la representación o propuesta, la decisión y su autoridad, la orden enviada al controlador o al dispositivo y la observación posterior. Una API que acepta la escritura del mapa no demuestra que un equipo recibiera la orden. Una orden aceptada tampoco demuestra que el servicio se recuperara.

La lógica es idéntica para un bucle cerrado. La topología apoya la observación y el análisis; el bucle incluye además una acción autorizada y nueva evidencia de resultado. Sin feedback independiente, el sistema solo sabe que actualizó su proceso.

Un recibo útil para cada consulta

Las consultas que influyen en una operación deberían conservar servidor, instancia y versión del modelo; rol y alcance de acceso del cliente; capa y nivel de abstracción; fuentes externas; horas de captura; sentido de la relación recorrida; estado de sincronización y filtros. Si hubo una acción, deben quedar aparte su aprobación, actuación, observación y posible rollback.

SIMAP gana valor cuando sus límites viajan con su respuesta. El resultado no tiene que proclamar “esta es la red”. Basta una afirmación más útil: esta es la dependencia que este servidor representó para este cliente, con estas fuentes y en este momento.

Fuentes

Documento y estado: SIMAP, revisión 13 e historial del Datatracker. Base y controles relacionados: RFC 8345, RFC 8341, RFC 8040, RFC 9417 y RFC 9408. El borrador YANG de SIMAP es un Internet-Draft individual sin posición formal en el proceso del IETF. Texto fuente congelado: archivo de la revisión 13. Contexto de ingeniería de tráfico: RFC 9522.