Resumen

  • La revisión de telechat del 1 de octubre sobre la revisión 20 del modelo base de inventario IVY propone aclarar que el controlador superior debe garantizar que los ne-id de su inventario combinado sean únicos.
  • Esa garantía evita una lista inválida, pero no resuelve por sí sola si dos registros con claves iguales son equipos distintos o si dos claves distintas nombran el mismo equipo.

El controlador del norte recibe dos registros. Ambos se llaman 17. Uno procede de una red de transporte y representa un equipo óptico; el otro llega de una red IP y representa un router. Cambiar el segundo 17 por 18 parece una solución trivial. No lo es si el sistema pierde la relación con la identidad original y luego una alarma, una orden de trabajo o una referencia topológica intenta regresar al dominio de origen.

Ese es el límite que hizo visible Linda Dunbar en su revisión del Routing Area Directorate, terminada el 1 de octubre. El resultado publicado es Has nits: el documento se considera claro en general y se plantea un asunto menor. Cuando un controlador de nivel superior combina inventarios de varios controladores inferiores, dice la revisión, ese controlador actúa como servidor de la vista resultante. Como ne-id lo asigna el servidor y es la clave de network-element, parece responsable de que los valores expuestos sean únicos.

La precisión evita exageraciones. draft-ietf-ivy-network-inventory-yang-20 es un Internet-Draft activo del grupo IVY, pensado para Standards Track y sometido a evaluación del IESG. No es un RFC ni una prueba de despliegue. La revisión no documenta una caída, un ataque o un fallo de producto. Pide que una responsabilidad ya implícita en la arquitectura quede mejor expresada.

El borrador ofrece un inventario genérico y de solo lectura sobre elementos de red y componentes que un controlador sabe instalados. No pretende abarcar repuestos de almacén, compras o todos los datos comerciales. Dentro del alcance del modelo, el controlador que entrega la información es la fuente de verdad. Fuente de verdad significa autoridad sobre esa representación concreta; no transforma la representación en el objeto físico.

El propio texto explica por qué el servidor asigna ne-id: el identificador local de un dispositivo no garantiza unicidad en toda la red. A la vez, espera que el mismo elemento conserve el mismo ne-id aunque se desconecte. El mecanismo para reconocerlo—fabricante, producto, dirección de gestión, ubicación física u otra señal—queda fuera de la normalización y depende de la implementación.

Al agregar dominios aparecen dos clases de conflicto. En el primero, dos objetos distintos comparten clave local. En el segundo, el mismo objeto aparece con claves diferentes porque dos controladores lo observan desde ámbitos superpuestos. Prefijar una clave con el nombre del dominio resuelve la primera colisión. No responde a la segunda, y puede consolidar para siempre un recuento duplicado.

Un error de separación puede inflar capacidad, alarmas y mantenimiento. Un error de fusión puede ser peor: dos chasis distintos terminan tratados como uno y una acción destinada a un equipo se atribuye al otro. Comparar etiquetas tampoco basta. Direcciones de gestión cambian; ubicaciones se reciclan; nombres de fabricante y producto se repiten; un controlador puede trabajar con información más antigua que otro.

El UUID común añade una referencia fuerte, no un veredicto. La revisión 20 lo describe como globalmente único y asignado por el servidor; el estándar UUID define formatos y propiedades. Sin embargo, un mismo activo puede recibir dos UUID de dos servidores, y una copia defectuosa puede hacer que dos objetos compartan uno. La unicidad del valor no prueba la continuidad del objeto que pretende nombrar.

Conviene separar cinco capas: el activo físico; lo que observó cada controlador inferior; su ne-id local; la decisión de reconciliación del agregador; y el ne-id combinado que consume la automatización. Validar la lista YANG solo establece una propiedad de la cuarta capa. No certifica el descubrimiento, la identidad física ni el resultado de una acción posterior.

La propuesta de control de BTW es un recibo reversible de traducción de identidad. Asociaría controlador fuente y ne-id fuente con ne-id combinado, UUID y anclas de hardware disponibles. Guardaría regla de coincidencia, confianza, conflicto, primera y última observación, sustituciones y las decisiones relevantes que consumieron la relación.

No es un requisito del borrador ni de la revisora. Es una propuesta editorial para evitar que el saneamiento de una clave borre la evidencia. Si B-17 pasa a ser 18, debe existir ruta de vuelta. Si A-17 y B-42 se fusionan tras nueva evidencia, el historial de sus afirmaciones previas debe permanecer. Si la correspondencia es dudosa, un estado de conflicto dice más verdad que una fila impecable.

Las notas de Heng Lu aportan una disciplina útil. La Nota 20 separa realidad ejecutable y representación simbólica: el registro dirige procesos, pero no se convierte en el equipo. La Nota 64 reserva la capa común para invariantes mínimos y verificables de unicidad e interoperabilidad, dejando las decisiones futuras a quienes ejecutan el sistema. La Nota 19 distingue coordinación de autoridad. Aquí, la clave única pertenece al contrato común; la reconciliación y su evidencia pertenecen al agregador local; ninguna etiqueta otorga soberanía sobre el activo. Es una lectura de BTW, no una posición que se atribuya a IETF.

El mecanismo tampoco repite las piezas vecinas. El mapeo de topología aborda referencias manuales a puertos; el inventario de derechos separa licencias, activación y servicio; el inventario pasivo necesita custodia para activos que no se informan a sí mismos. Este artículo se queda en la frontera anterior: cómo una identidad cruza de un espacio local a una vista combinada sin perder origen ni incertidumbre.

La revisión 20 permite expresamente que un controlador jerárquico recoja datos de controladores inferiores y ofrezca el conjunto a otro controlador, un OSS de inventario u otra aplicación. También menciona ACTN como contexto posible. Por ello, una aclaración útil debe decir dónde se evalúa la unicidad y quién responde de ella. La norma no tiene que imponer un algoritmo mundial de coincidencia; basta con no dejar invisible la transferencia de responsabilidad.

Fuentes