<div dir="ltr">Добрый день. <br><br>Это вспомогательный материал к презентации об инструментации BGP на ENOG немного позднее сегодня. Так как формат виртуальной конференции не особенно подходит для детальных дискуссий, и сама тема нагружена множеством технических деталей, здесь представлена суммаризованнаы версия тем для дискуссии. Да и формат электронной почты немного ближе листа бумаги, на котором можно изобретать и пробовать идеи. <br><br>BGP работает, и это прекрасно. И мы понимаем, что и как там работает. Или делаем вид, что понимаем. Или надеемся, что работает именно так, как надо. Или просто верим, что это будет работать. А если не работает - всегда можно взять телефон и спросить у соседа, что там видно на другой стороне. Ситуация, наверное, знакомая до боли многим операторам. <br><br>Можно ли сделать что-то для более детальной диагностики работы протокола? Нужно ли? Какая цена такой функциональности представляется вам логичной и реалистичной? А вашему отделу ИТ безопасности? А вашему директору по продажам? То, что можно спроектировать очередное расширение протокола BGP и поверх него слать SMS - это очевидно, но решает ли это изначальные проблемы? Есть ли договоренность между операторами о общем наборе диагностических механизмов, которые нужны для обслуживания BGP? <br><br>А если попробовать?<br><br>Эта тематика не является новой, и в этой презентации не представляются еще какие-то новые расширения протокола - их у нас и так достаточно. Чего не хватает - это обобщенное понимание со стороны операторского сообщества о том, что является важным для мониторинга работы БГП, чего не хватает в существующих механизмах, и какая функциональность вам была бы нужна повседневно. За последние 20 лет в IETF было несколько попыток разработки универсального механизма для инструментации БГП, но большинство тех предложений застряло по пути. И это не странно - так как аудитория инженеров, работающих над расширениями протоколов в IETF, и аудитория инженеров, работающих с теми самыми протоколами на реальных сетях почто не пересекаются - это просто проблема не знания потребностей и методик работы со стороны операторов. <br><br>Многие операции над более чем одним роутером БГП сегодня делаются или вручную, или при помощи (как правило, доморощенных) решений автоматизации, сам протокол почти не имеет механизмов для обмена информацией о работе самого протокола. Это исторический подход UNIX way - и действительно, БГП делает свою работу хорошо. Но времена меняются, и потребность в довольно рутинном функционале проверки работы политик БГП, сбора статистики, сбора информации об ошибках, разделения границ ответственности между компонентами протокола - все это становится нужным повседневно.<br><br>БГП - это односторонний протокол, в нем нет возможности узнать приняли ли сосед наш префикс, и будет ли он этот префикс пользовать. Такая сигнализация может дать нам автоматическую проверку работы политик БГП. Также в протоколе нет никаких решений для индикации нефатальных ошибок - любая ошибка приводит к обрыву сессии. И нет механизмов для обмена информацией о статистике работы протокола - сколько и чего было послано, принято, отброшено. Это три большие группы функциональности, которые нужны для повседневных операций. Весь вопрос в договоренности, какие конкретно функции и какие параметры нужны - нет цели сделать универсальный и подходящий для всех применений механизм, но должна быть обеспечена покрытие большинства функций, которые нужны для большинства операторов. <br><br>Часть; времени доклада после ввода в тематику и обзора исторических событий будет оставлена для дискуссий. Хотелось-бы, что та дискуссия перешла в почту и продолжалась. Здесь нет спешки по времени, эти темы постепенно представляются операторскому сообществу и список нужного функционала накапливается, и планы по представлению в IETF идут на следующий год. <br><br><div>Спасибо. <br></div><div><br></div><div><br></div><br><br></div>