Кратко

  • В telechat-рецензии от 1 октября предложено уточнить: верхний контроллер, публикующий объединённую инвентаризацию, должен обеспечить уникальность ne-id в собственной выдаче.
  • Уникальный ключ устраняет структурную коллизию, но отдельно требуется понять, являются ли две записи разными устройствами с одинаковым локальным ID или одним устройством с разными ID.

Один нижний контроллер называет пограничный маршрутизатор номером 17. Другой использует 17 для оптического шасси. В пределах каждого домена ключ уникален. Противоречие появляется только тогда, когда верхний контроллер обещает представить обе базы как один список.

Именно эту границу отметила Linda Dunbar в рецензии Routing Area Directorate на редакцию 20 draft-ietf-ivy-network-inventory-yang, завершённой 1 октября. Результат — Has nits: документ в целом ясен, но есть небольшой вопрос. Поскольку ne-id назначается сервером и служит ключом списка network-element, верхний контроллер, действующий как сервер объединённой инвентаризации, должен отвечать за уникальность публикуемых значений.

Это не сообщение об аварии. Редакция 20 — действующий Internet-Draft рабочей группы IVY, предназначенный для Standards Track и находящийся на оценке IESG с последующим рассмотрением Area Director. Это не RFC. Рецензия не доказывает реальную коллизию, уязвимость или дефект продукта. Она выявляет архитектурную ответственность.

Проект описывает универсальную инвентаризацию только для чтения: сетевые элементы и компоненты, которые контроллер считает установленными. Складские запасы, закупки и коммерческие данные находятся вне базовой модели. В её пределах предоставляющий данные контроллер назван источником истины. Это ответственность за представление, а не превращение записи в физическую реальность.

Сервер назначает ne-id, потому что локальный идентификатор устройства не обязан быть уникальным во всей сети. При этом один и тот же сетевой элемент должен сохранять ID даже во время отключения. Как установить тождество—по производителю, продукту, управляющему адресу, физическому месту или другому признаку—решает реализация.

На границе агрегации возникают две задачи. Первая — не допустить одинаковых ключей в одном YANG-списке. Вторая — согласовать идентичность наблюдаемых объектов. Префикс домена решает первую. Он не сообщает, являются ли A-17 и B-42 одним шасси.

Ошибочное разделение создаёт двойной учёт устройства, ёмкости, тревог и обслуживания. Ошибочное слияние связывает два разных устройства и может направить действие не к тому объекту. Управляющие адреса меняются, сведения о месте устаревают, названия моделей повторяются. Поэтому конфликт — полезное состояние, а не мусор, который нужно скрыть.

UUID даёт сильную ссылку, но не окончательный вывод. Редакция 20 описывает его как глобально уникальное значение, назначаемое сервером, а RFC о UUID задаёт формат и свойства генерации. Тем не менее два сервера могут выдать одному физическому устройству разные UUID, а ошибочное копирование — двум объектам один. Уникальность значения и тождество объекта различны.

Нужно разделять как минимум пять уровней: физический актив; наблюдение нижнего контроллера; локальный ne-id; решение верхнего уровня о сопоставлении; комбинированный ne-id, который используют тревоги, топология, задания и автоматизация. Корректная YANG-структура подтверждает только форму последнего представления.

Редакционное предложение BTW — обратимая квитанция преобразования идентичности. Она связывает исходный контроллер и исходный ne-id с комбинированным ne-id, UUID и доступными аппаратными опорами. В ней фиксируются правило сопоставления, уверенность, конфликт, первое и последнее наблюдения, история замены и значимые решения, использовавшие эту связь.

Такого требования нет ни в проекте, ни в рецензии. Это контрольная мера BTW, позволяющая переименовывать, не забывая. Если B-17 становится 18, обратный путь сохраняется. Если позднее A-17 и B-42 признаются одним шасси, слияние не стирает историю двух прежних утверждений. При слабых доказательствах открытый конфликт честнее аккуратной строки с ложной определённостью.

Подход опирается на раскрытую аналитическую рамку Heng Lu, но не приписывает её IETF. Note 20 разделяет исполнимую реальность и символическое представление. Note 64 оставляет в общей системе лишь минимальные проверяемые инварианты уникальности и совместимости, а последующие решения — операторам. Note 19 отделяет координацию от власти. Здесь общая модель требует уникального ключа; локальный агрегатор отвечает за сопоставление и доказательства; никакой ID не даёт власти над физическим активом.

Соседние статьи сохраняют свои темы. Топологическое отображение касается ручных переопределений ne-ref и port-ref; учёт прав — разницы между лицензией, активацией и услугой; пассивная инвентаризация — доказательств для объектов, которые не могут сообщить о себе. Здесь вопрос предшествует им: как идентичность пересекает домены и не теряет источник.

Проект прямо разрешает иерархическому контроллеру собирать данные нижних контроллеров и отдавать объединённую картину ещё одному контроллеру, Inventory OSS или приложению; ACTN указан как возможный контекст. Стандарту не нужна единая мировая процедура matching. Но он должен показать границу сервера, где обеспечивается уникальность, а реализация — оставить проверяемую историю перевода и конфликтов.

Источники