Кратко

  • Планируемое добавление нельзя использовать, пока обычные механизмы liveness IS-IS не подтвердят работу всех нужных смежностей.
  • Планируемое удаление устроено иначе: орбитальная физика делает потерю почти неизбежной, поэтому метрику и TE-маршруты следует изменить до исчезновения канала.
  • Полномочия расписания, получение, наблюдаемая смежность, сходимость, расчёт PCE, состояние оборудования и клиентский результат требуют отдельных квитанций.

Зелёная линия на орбитальной карте

В 14:00 центр управления рисует зелёную линию между двумя спутниками. Геометрия вошла в окно возможной оптической связи. PCE уже рассчитал путь Segment Routing через это ребро, а ingress подготовил стек меток.

Расписание может быть подлинным, а расчёт — правильным для прогнозного графа. Это не доказывает, что оптические терминалы захватили друг друга, канальный уровень работает, смежность IS-IS образована или пакет пересёк канал. Прогноз ценен тем, что появляется раньше реальности; он опасен, когда это опережение принимают за власть над реальностью.

RFC 9717 проводит важную асимметрию. Прогноз соединения не гарантирует соединение. Разрыв, вызванный орбитальной динамикой, практически неизбежен. Физика может закрыть окно, но не обещает, что терминал, наведение и управление успешно его открыли.

Полномочия документа также ограничены. Это Informational RFC независимого потока, опубликованный в январе 2025 года. Он выражает мнение автора, не является продуктом IETF или консенсусом сообщества и не предлагает изменений протокола. Публикация не доказывает проверку, внедрение или принятие.

Расписанию нужна идентичность

Плоскость управления должна передать планируемые изменения всем узлам L1/L2, шлюзам и PCE, которые будут принимать решения. Точный способ распространения вне сферы документа. Поэтому запись должна включать издателя, версию, время создания, срок действия, получателей, подтверждения и историю замены. Иначе два контроллера могут говорить, что используют «расписание», но действовать в разных будущих.

Получение не означает применение. Спутник может иметь правильную версию и неисправный терминал; шлюз — пропустить редакцию; PCE — обновить базу до прихода изменения. Прогноз нужно связать с моментом, когда каждый участник действительно его принял.

Добавление ждёт liveness

Новый канал или узел не должен вызывать функционального изменения, пока обычный liveness IS-IS не докажет все необходимые смежности. Таблицы и пути можно рассчитать заранее, но нельзя устанавливать маршрут через новую топологию до подтверждения.

Предварительный расчёт доказывает входной граф, ограничения, версию алгоритма, время и список SID. Он не доказывает существование пути. После смежности LSDB, BGP-LS и база PCE ещё должны показать один текущий граф.

Предварительная установка требует доказуемого отката, если топология не заработает: триггер, владелец, срок, затронутые метки и подтверждение удаления устаревшего состояния. «Установлено успешно» неполно, если состояние зависит от будущего физического события.

Удаление требует раннего действия

Ждать, пока liveness объявит канал мёртвым, значит потерять преимущество прогноза. RFC советует заранее поднять метрику, чтобы изменение распространилось и IGP сошёлся; шлюзы и PCE также должны установить обходы до потери.

Единого запаса времени нет. Он зависит от масштаба, конфигурации, распространения, расчёта и программирования оборудования. Следует хранить ожидаемый момент разрыва, изменение метрики, разброс LSDB, новый расчёт, аппаратное подтверждение и последний пакет на старом канале. RFC предпочитает видимый сигнал IGP скрытому локальному исключению, уменьшая риск неполной информации и рассинхронизации.

Восемь утверждений об одном пути

Архитектура сочетает IS-IS, Area Proxy, орбитальные stripes, SR-MPLS и расчёт шлюзом или PCE. Аудит различает: авторизованный план; одинаковую полученную версию; наблюдаемую смежность; сошедшуюся топологию; рассчитанный путь; установленное состояние; фактически использованный маршрут; измеренный сервис.

Квитанция оборудования не доказывает удалённый оптический канал. Смежность не доказывает ёмкость. Чистая LSDB не доказывает правильный стек меток. Один клиентский тест сам по себе не выявляет старый вход PCE. Доказательность появляется благодаря общему идентификатору изменения и единой временной линии, не стирающей границы слоёв.

Архитектура ещё нуждается в проверке

RFC предполагает, что граф почти всегда связан, работающих каналов и общей полосы достаточно, а расписание обычно точно. Если пути нет, допускается потеря пакетов и не требуется хранение с последующей передачей. Это проектные предпосылки, а не измерения конкретной группировки.

Раздел будущей работы признаёт: точная статистика ISL не публикуется, допустимые углы, расстояния и скорость слежения неизвестны, размер stripe нужно проверять моделированием и эксплуатацией. Он может включать несколько орбит или тысячи спутников и выйти за пределы реализации IGP.

Ответственное чтение — не сертификация и не отказ. Расписание способно уменьшить предотвратимые потери, особенно перед неизбежным разрывом. Существующие протоколы дают правдоподобные блоки. Но прогноз не подтверждает сам себя, путь не устанавливает сам себя, а зелёная плоскость управления не доставляет сервис.

Источники

Первичные записи: RFC 9717, карточка RFC Editor, история проекта и IETF conflict review. Контекст: RFC 9666, RFC 8402, RFC 8660, RFC 4655 и RFC 9552.

Открытая редакционная рамка: реальность, а не защита позиции.