Кратко

  • Текущий текст draft-xu-idr-fare-in-mpson-01 датирован 16 августа 2026 года и переносит идею взвешенного ECMP по пропускной способности из FARE-BGP на RoCE NIC (RNIC) в многоплоскостных scale-out сетях.
  • Эксплуатационная задача состоит из выбора между изолированными CLOS-плоскостями на RNIC и ограничения объёма host-маршрутов, которые нельзя безгранично хранить повсюду.

Карточка IETF Datatracker называет документ Fully Adaptive Routing Ethernet in Multi-Plane Scale-Out Networks. Это Internet-Draft с предполагаемым статусом Standards Track. Отсюда следует важная граница: IETF относит такие документы к рабочим текстам, которые могут меняться, заменяться или истекать, а не к уже принятому стандарту.

Текст версии -01 описывает RNIC, подключённую к независимой CLOS-fabric в каждой плоскости. Связей между плоскостями нет, поэтому RNIC выбирает плоскость для пакета или потока. Предложение расширяет FARE-BGP — взвешенный ECMP, опирающийся на Path Bandwidth Extended Community, — от коммутаторов до этого интерфейса. Для каждой плоскости RNIC устанавливает отдельную BGP-сессию с leaf-коммутаторами и через неё узнаёт удалённую достижимость и сведения о пропускной способности для взвешенного выбора.

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

Второе ограничение — масштаб. В иллюстративном примере указаны 100 000 GPU и четыре плоскости, причём каждая может распространять до 100 000 host-маршрутов. Хранить все 400 000 маршрутов на каждой RNIC непрактично, а полностью удерживать их на коммутаторах нежелательно; поэтому предлагается подавление таблиц. Но агрегация может остаться после того, как удалённая RNIC стала недостижима через одну плоскость. Чтобы избежать чёрной дыры, проект связывает агрегацию с явным объявлением о недостижимости хоста; один из вариантов — значение Path Bandwidth, равное нулю. Это проектное решение, не свидетельство внедрения или совместимости.