Кратко

  • RFC 5195 распространяет членство PE и сопоставления клиентских и провайдерских портов, чтобы последующая сигнализация могла завершить создание соединения. Запись в PIT — вход для этой работы, а не квитанция о результате.
  • Между обнаружено и передаёт трафик остаются проверка полномочий источника, импорт, сигнализация, допуск, резервирование, аппаратное кросс-соединение и проверка тракта. Каждый переход требует собственного наблюдателя.

Существительное, которое съело процесс

Слово «соединение» удобно. Оно позволяет скрыть многоступенчатую процедуру за одним состоянием. В L1VPN это особенно опасно, потому что обнаружение действительно сообщает сведения, необходимые для будущего соединения, и потому внешне похоже на его начало.

RFC 5195 определяет BGP-механизм автоматического обнаружения. PE сообщает собственный адрес и локальные пары частного и провайдерского адресов. Удалённые PE находят общие VPN и используют полученные данные для разрешения адресов во время сигнализации.

Формулировка не оставляет оснований для сокращения: сведения необходимы для завершения фазы сигнализации. Сама рассылка не является этой фазой. Она не принимает ресурсное решение и не меняет состояние оптического оборудования.

Модель single-end provisioning означает, что при добавлении порта конфигурацию можно менять только на локальном PE и подключённом CE. Она уменьшает ручной ввод, но не отменяет удалённое исполнение.

Строка PIT и её предел

Для каждого L1VPN с локальным портом PE поддерживает Port Information Table. Она содержит пары <CPI,PPI>. CPI уникален в пределах конкретного VPN, PPI — в сети провайдера.

Локальная часть поступает от подключённых CE или конфигурации. Удалённая — через BGP auto-discovery. Общий формат помогает сигнализации, но строка сохраняет происхождение. Полученное утверждение не превращается в факт о физическом устройстве только потому, что попало рядом с локальными данными.

Минимальная честная шкала состояний выглядит длиннее: объявление принято, политика импорта совпала, строка установлена в PIT, полномочие источника подтверждено, сигнализация отправлена, admission разрешён, ресурс зарезервирован, кросс-соединение создано, непрерывность и трафик проверены.

Каждое состояние может завершиться неудачей после успеха предыдущего. Именно поэтому одно зелёное поле не должно наследовать доказательства следующих этапов.

Аутентифицированный сосед не подписывает происхождение

RFC 5195 требует, чтобы PE обнаруживался в VPN только при реальном подключении и надлежащей авторизации. Для прямого BGP-соседа документ рекомендует механизм аутентификации RFC 2385; RFC 5925 позднее описал TCP Authentication Option.

Такая защита устанавливает личность непосредственного участника сессии. Если объявление пришло через промежуточных говорящих BGP, исходный PE может находиться несколькими доверительными переходами дальше.

Локальный PE вынужден доверять тому, что сосед принимает информацию только от тех, кому сам доверяет, и так по всей цепочке. RFC называет это транзитивным доверием и прямо признаёт: BGP не позволяет определить, что конкретный полученный элемент возник у говорящего, уполномоченного объявлять именно его.

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

Route Target отвечает на другой вопрос

Export Route Targets помечают локальную информацию, а import Route Targets ограничивают набор, который может попасть в PIT. Совпадение отвечает на вопрос: выбрала ли местная политика это объявление?

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

При VPN Join новый import target меняет ожидаемый набор. Ранее PE обязан был отбрасывать информацию без совпадения; теперь он должен получить её заново. RFC 5195 требует Route Refresh. Поэтому commit, refresh, повторный приём и сверка PIT — четыре квитанции.

При VPN Prune маршруты, потерявшие последнее совпадение, могут быть удалены. BGP-сессия остаётся активной. Её стабильность не доказывает, что устаревшая пара исчезла из оркестратора и других потребителей.

Плановая величина не становится резервом

Обнаружение может переносить switching capability и максимальную полосу LSP удалённого интерфейса для выбора выхода. Это объявленный параметр. Он не обязательно равен текущему свободному ресурсу и не подтверждает резервирование под запрос.

Следует хранить источник и время атрибута, отдельно измерение, решение admission и идентификатор резерва. Если одно поле переименовывают из maximum в available, а затем в reserved, система дважды меняет смысл без нового факта.

Частичная видимость заложена в масштабирование

Route reflectors разрешено делить по VPN; независимых BGP-систем для VPN-информации может быть несколько. Это освобождает любой один компонент от обязанности знать всё.

Следовательно, полнота PIT всегда относится к объявленной области. Экран должен назвать discovery-раздел, ожидаемых производителей, версию политики, состояние refresh и момент сверки. Две разные группы членов могут быть согласованы каждая в своём контуре.

Квитанция, которая заканчивается в плоскости данных

Для пары сохраняются VPN, CPI, PPI, локальное или удалённое происхождение, ближайший сосед, наблюдаемый origin, Route Targets, решение импорта и основание полномочий. Отдельно фиксируются приём, установка, отзыв, срок действия и подтверждение потребителей.

Затем начинается исполнительная цепочка: запрос сигнализации, ответ, допуск, резерв, состояние кросс-соединения, проверка непрерывности и передача трафика. Это операционная модель, а не новое требование к формату RFC 5195.

Она реализует дисциплину Heng Lu о слоях реальности. Конфигурация выражает намерение, BGP переносит заявление, PIT строит представление, устройство исполняет. Минимальная спецификация должна сохранить переносимые квитанции между ними. Тогда автоматизация может быть быстрой, не получая права объявлять несуществующий оптический путь.

Источники

  1. RFC 5195 в HTML
  2. Текст RFC 5195
  3. Информационная страница RFC 5195
  4. IETF Datatracker: RFC 5195
  5. История RFC 5195
  6. Ссылки RFC 5195
  7. Исправления RFC 5195
  8. RFC 4847
  9. RFC 5251
  10. RFC 4760
  11. RFC 4360
  12. RFC 4684
  13. RFC 2918
  14. RFC 5291
  15. RFC 2385
  16. RFC 4271
  17. RFC 5925
  18. Heng Lu — слои реальности и символическая власть
  19. Heng Lu — минимальная начальная спецификация
  20. Heng Lu — первичность работающего кода