По факту фильтры из одной плоскости должны будут перейти в другую. Что мне будет мешать в фильтре заанонсить соседу 8.8.8.0/24 и потом следом префикс?

1. AF поднимается по механизму capabilities - если сосед поддерживает, то будем слать все подряд, если не поддерживает - ничего слать не будем, это стандартное поведение всех AF без вмешательства оператора.

2. Это не первая и не последняя попытка из BGP сделать универсальный транспортный протокол для синхронизации баз данных. Главная проблема здесь - нехотение понять, что если что-то сделать можно, то не обязательно так и делать.

Но так интересно наблюдать как реагируют разные реализации dns на наличие одновременно cname и ещё A-record )

4. А обратной сигнализации и нет - по определению, так как BGP работает только в одну сторону, там нет механизма извещения о том, что другая сторона что-то сделала (кроме notification, сигнализации refresh, и динамичесских capabilities, что еще надо суметь найти в реализации). И то, что удаленный узел пока еще обрабатывает наш новый rpd префикс, он отдан на policy компонент, полицы компонент смог или не смог его поставить на работу по какой-то причине, были ли конфликты какого-то рода, и многое другое - это не видомо для локального узла. Нет сортировки или какого-то упорядованивания, так как по мнению авторов полкитика - это несортированный список префиксов, аттрибутов, и действий. :-/

6. Это немного грустно, так как идея то не плохая, но реализация все портит. На уровне реализации нет flowspec фильтров для самих flowspec апдейтов. Это проблема реализации и договора между собой участников сообсшества - IETF здесь делать не особо что есть. То же самое верно и для rpd - для хоть какого серьезного использования между AS нужен rpd филтьр для rpd апдейтов. И да, его можно передавать по rpd. :-) :-)

6. Это немного грустно, так как идея то не плохая, но реализация все портит. На уровне реализации нет flowspec фильтров для самих flowspec апдейтов. Это проблема реализации и договора между собой участников сообсшества - IETF здесь делать не особо что есть. То же самое верно и для rpd - для хоть какого серьезного использования между AS нужен rpd филтьр для rpd апдейтов. И да, его можно передавать по rpd. :-) :-)

В чем смысл тогда этого всего? Сейчас все по бд, где хоть какая-то валидация есть, ну и плюс визуальная проверка у тех кто автоматизировал процесс. Идея ж изначальная дать гибкость, а с учётом нюанса этого как определять, что можно, а что нет?

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

Это не затрагивает аспектов source of truth - изначалное представление конфигурации в валидном состоянии каким-то образом попадает на один узел, а тот размазывает ту конфигурацию по сети. Да, сегодня это все работает по конфигурационному каналу. Визия у авторов этого подхода - отпилить конфигурационный канал и делать все по BGP. Им видется, что так будет лучше.

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

Сам документ - https://datatracker.ietf.org/doc/draft-ietf-idr-rpd/

Большинство деталей там - для имплементоров, вам как операторам не особенно важно, какой бит на проводе отвечает за что, и все диаграммы и списки могут и устрашить. Чего нет в документе - это интерпретации функционала, который как раз здесь и описан.

Несколько вопросов сообществу - если можете, расскажите свое мнение, чем более развернуто, тем лучше. Попробую собрать агрегированные ответы и передать в сторону IETF.

Q1. Видите ли вы потребность в практическом формате описания политик роутинга, независимого от реализаций конкретного вендора? Акцент на "практический" - такой, который позволяет выразить ваши имеющиеся политики с сохранением функциональности. Это охватывает общий набор операций по соответствию и модификации атрибутов и набор точек подключения таких политик.

Q2. Видите ли вы потребность в контролировать политику не по конфигурационному каналу в объеме больше, чем это позволяет ORF?

Q3. Видите ли вы потребность в механизме управления политикой через административную границу в оба направления? Видите ли вы потребность управлять удаленным узлом? Видите ли вы потребность разрешить удаленному узлу управлять политикой на вашем локальном узле?

Q4. Подходит ли multipoint парадигма распространения информации по BGP для такого механизма?

Q5. Как вы оцениваете уровень операционной сложности такого механизма - те результаты, которые потенциально могут быть достигнуты при использовании распространения политик по BGP, оправдывают ли они свою цену потенциального полного изменения формата и методологий политик?

Открыл чтобы убедиться в предположении что это за "один вендор". Ну естессно, кто же ещё.

Тоже угадал с первой ноты? :)

Ну так, но надеялся что может есть кто ещё с такими "идеями"

Типа ZTE? :)