Добрый день. Это вспомогательный материал к презентации об инструментации BGP на ENOG немного позднее сегодня. Так как формат виртуальной конференции не особенно подходит для детальных дискуссий, и сама тема нагружена множеством технических деталей, здесь представлена суммаризованнаы версия тем для дискуссии. Да и формат электронной почты немного ближе листа бумаги, на котором можно изобретать и пробовать идеи.
BGP работает, и это прекрасно. И мы понимаем, что и как там работает. Или делаем вид, что понимаем. Или надеемся, что работает именно так, как надо. Или просто верим, что это будет работать. А если не работает - всегда можно взять телефон и спросить у соседа, что там видно на другой стороне. Ситуация, наверное, знакомая до боли многим операторам. Можно ли сделать что-то для более детальной диагностики работы протокола? Нужно ли? Какая цена такой функциональности представляется вам логичной и реалистичной? А вашему отделу ИТ безопасности? А вашему директору по продажам? То, что можно спроектировать очередное расширение протокола BGP и поверх него слать SMS - это очевидно, но решает ли это изначальные проблемы? Есть ли договоренность между операторами о общем наборе диагностических механизмов, которые нужны для обслуживания BGP? А если попробовать? Эта тематика не является новой, и в этой презентации не представляются еще какие-то новые расширения протокола - их у нас и так достаточно. Чего не хватает - это обобщенное понимание со стороны операторского сообщества о том, что является важным для мониторинга работы БГП, чего не хватает в существующих механизмах, и какая функциональность вам была бы нужна повседневно. За последние 20 лет в IETF было несколько попыток разработки универсального механизма для инструментации БГП, но большинство тех предложений застряло по пути. И это не странно - так как аудитория инженеров, работающих над расширениями протоколов в IETF, и аудитория инженеров, работающих с теми самыми протоколами на реальных сетях почто не пересекаются - это просто проблема не знания потребностей и методик работы со стороны операторов. Многие операции над более чем одним роутером БГП сегодня делаются или вручную, или при помощи (как правило, доморощенных) решений автоматизации, сам протокол почти не имеет механизмов для обмена информацией о работе самого протокола. Это исторический подход UNIX way - и действительно, БГП делает свою работу хорошо. Но времена меняются, и потребность в довольно рутинном функционале проверки работы политик БГП, сбора статистики, сбора информации об ошибках, разделения границ ответственности между компонентами протокола - все это становится нужным повседневно. БГП - это односторонний протокол, в нем нет возможности узнать приняли ли сосед наш префикс, и будет ли он этот префикс пользовать. Такая сигнализация может дать нам автоматическую проверку работы политик БГП. Также в протоколе нет никаких решений для индикации нефатальных ошибок - любая ошибка приводит к обрыву сессии. И нет механизмов для обмена информацией о статистике работы протокола - сколько и чего было послано, принято, отброшено. Это три большие группы функциональности, которые нужны для повседневных операций. Весь вопрос в договоренности, какие конкретно функции и какие параметры нужны - нет цели сделать универсальный и подходящий для всех применений механизм, но должна быть обеспечена покрытие большинства функций, которые нужны для большинства операторов. Часть; времени доклада после ввода в тематику и обзора исторических событий будет оставлена для дискуссий. Хотелось-бы, что та дискуссия перешла в почту и продолжалась. Здесь нет спешки по времени, эти темы постепенно представляются операторскому сообществу и список нужного функционала накапливается, и планы по представлению в IETF идут на следующий год. Спасибо.
_______________________________________________ discuss mailing list discuss@enog.org https://lists.enog.org/mailman/listinfo/discuss
