Кратко

  • IETF опубликовала редакцию 38 проекта о получении междоменной топологии через BGP-LS 19 августа в 09:22:08 UTC. Единственное содержательное изменение относительно редакции 37 — удаление Multi-Topology Identifier, TLV 263, из предлагаемого списка дескрипторов Inter-AS Link NLRI.
  • MT-ID не исключён из BGP-LS. Изменился предлагаемый состав идентификатора нового объекта, поэтому следующими доказательствами должны стать корректное снятие старой записи, отсутствие дублей и сохранение границ между нестандартными топологиями.

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

История Datatracker фиксирует появление draft-ietf-idr-bgpls-inter-as-topology-ext-38 19 августа в 09:22:08 UTC. Структурное сравнение официальных текстов редакций 38 и 37 показывает: помимо номера и даты, техническая правка одна — строка с TLV 263 удалена.

Проект закрывает пробел между доменами IGP. BGP-LS по RFC 9552 может передавать топологию каждого домена потребителю, например приложению SDN. Если один оператор управляет несколькими доменами и AS, контроллер получает отдельные внутренние карты, но не обязательно видит соединяющие их каналы.

Для этой границы документ предлагает NLRI типа 7 — Inter-AS Link — и TLV 270–272: номер удалённой AS, а также IPv4- и IPv6-идентификаторы удалённого пограничного маршрутизатора. Каждая сторона объявляет направленную половину канала. Потребитель связывает две половины, объединяет карты доменов и затем может рассчитать сквозной путь.

В редакции 37 после новых удалённых полей перечислялись локальный и удалённый идентификаторы канала, адреса интерфейса и соседа IPv4, их аналоги IPv6 и MT-ID. В редакции 38 список заканчивается адресом соседа IPv6. Следующее предупреждение сохранено: дополнительные TLV в роли дескрипторов могут затруднить сопоставление половин, если производители реализуют их по-разному.

Это не означает общего отказа от MT-ID. RFC 9552 по-прежнему определяет TLV 263 как Multi-Topology Identifier. Для обычного Link NLRI он обязателен, если канал IGP относится к нестандартной топологии; для каждого идентификатора топологии нужен отдельный NLRI. В разделе безопасности редакции 38 MT-ID также остаётся среди критически важных сведений о сети.

Изменён именно предлагаемый ключ нового Inter-AS Link NLRI. Производитель по редакции 37 может включать TLV 263 в идентификатор, а реализация по редакции 38 — опускать. Если потребитель сочтёт их разными ключами, одна половина канала останется в двух экземплярах. Если объединит без достаточной проверки, может потеряться различие между топологиями.

Правило перехода уже есть в RFC 9552. При добавлении, удалении или изменении TLV в Link-State NLRI производитель обязан снять прежний NLRI. Иначе в таблице BGP-LS могут остаться дублирующиеся и противоречивые объекты. Это основание для испытания, а не сообщение о случившемся сбое.

Отдельно предстоит согласовать реестр. При проверке 19 августа реестр параметров BGP-LS IANA указывал 7 августа как дату последнего обновления, называл тип 7 Stub Link NLRI и ссылался на редакцию 17. В редакции 38 он называется Inter-AS Link NLRI. Названия TLV 270–272 уже соответствуют удалённой AS и удалённому ASBR, однако ссылка также ведёт на редакцию 17.

Страница состояния документа показывает незавершённость процесса. Проект претендует на статус Proposed Standard, передан IESG и находится на этапе AD Followup. Состояние проверки IANA — Version Changed - Review Needed, экспертных проверок — Expert Reviews OK. Документ ещё не стал RFC, а открытых результатов совместимости реализаций нет.

Более полная карта создаёт и границу конфиденциальности. Проект рассматривает несколько AS под управлением одной организации и относит адреса, идентификаторы каналов, номера AS и топологию к критическим сведениям. Рекомендуется оставлять их внутри этого закрытого контура или фильтровать до выхода наружу. Данные, полезные автоматизации, одновременно точнее раскрывают внутреннее устройство сети.

Практический вывод — не немедленное внедрение, а программа приёмки. Нужно увидеть исчезновение идентичности редакции 37, одну новую запись, правильное объединение двух половин, раздельность нестандартных топологий и соблюдение административной границы распространения. Пока этих наблюдений нет, редакция 38 остаётся уточнённым проектом, а не доказанной возможностью.

Источники