Recently in new ietf stuff Category
На этой неделе в Дублине проходит очередная встреча IETF. Я сижу в Москве и наблюдаю издалека. На сегодня большая часть WG уже выложила свои материалы: https://datatracker.ietf.org/meeting/72/materials.html. Поэтому наблюдать интересно.
Несколько штучек, которые меня заинтересовали:
Virtual Aggregation
Некоторое время назад Paul Francis в grow@ietf рассказал про свою статью "Reducing FIB Size through Virtual Aggregation".
С тех пор он передумал и решил дополнить свой подход BGP-сигнализацией для некоторой автоматизации и, соотвественно, опубликовать свой драфт уже не в GROW, а в IDR. Что он и сделал в начале этого месяца, взяв в соавторы Xiaohu Xu из Huawei. В idr@ietf успели пообсуждать этот драфт немного, поэтому, скорее всего, надо ждать версии -01 в скором времени.
Суть предложенного подхода заключается в инжектировании довольно коротких префиксов (локальных для данной AS), и выкидывания из FIB (но не из RIB) префиксов более длинных. Если использовать правильную систему туннелей (например MPLS-туннелей), то это не приведет к циклам, но, естественно, может удлинить пути для трафика в данной AS. Статья показывает, что если выкидывать из FIB не все префиксы, а только "непопулярные", то можно достичь значительного сокращения объема FIB, не сильно ухудшив общую картину с оптимальностью путей трафика. Я в такой результат вполне верю: по словам коллеги из одного [довольно большого] оператора, на 120K префиксов уходит всего лишь около 1% трафика.
Кроме того, инжектирование покрывающих префиксов может помочь улучшить время сходимости. Здесь есть два фактора:
1) Покрывающий префикс распространяется независимо от специфичного и может служить своего рода fall back'ом для случая, когда next-hop специфичного префикса погиб. С несколькими одинаковыми префиксами обеспечить fallback труднее из-за того, что BGP-спикер анонсирует только лучший путь - это так называемая проблема path invisibility.
2) Маршрутизаторы, которые вбрасывают покрывающие префиксы, образуют уровень иерархии. Соответственно, как указал Robert Raszuk, само число роутеров, которые должны нести fallback пути, меньше. Плюс, если использовать BFD для быстрого обнаружения падения next-hop'ов, то BFD mesh серьезно уменьшается.
Надо сказать, в отношении BGP части у авторов получилась какая-то хуавейня, извините за выражение. Никакой особой автоматизации не получилось, а та, которая получилась, попросту опасна. Но это не отменяет ценности самого подхода, и, думается, что BGP часть поддается доработке.
Я эту конструкцию на прошлых выходных собрал в лабе. Работает (с некоторыми недочетами). Но получилось слишком сложно, чтобы рекомендовать это для реального внедрения прямо сегодня.
Текущая версия драфта: http://tools.ietf.org/html/draft-francis-idr-intra-va-00
Презентация на IETF72, кратко описывающая суть предложенного: http://www.ietf.org/proceedings/08jul/slides/idr-3.pdf
TANA
На этой встрече IETF запланирована BoF сессия TANA (Techniques for Advanced Networking Applications)
О чем речь? В одной из своих заметок я упоминал, что для peer-to-peer приложений пригодился бы новый транспортный протокол со специальным congestion control. Вот TANA именно про это. Цель в разработке алгоритма congestion control, который позволял бы p2p не мешать интерактивным задачам, но тем не менее эффективно утилизировал бы полосу, когда она не затребована другими приложениями. Насколько я понял, технология уже есть и используется в Bittorrent DNA.
BoF session по TANA будет 31-го июля. С нетерпением жду minutes.
TANA BoF agenda: http://www.ietf.org/proceedings/08jul/agenda/tana.txt
TANA Problem Statement: http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statement-01.txt
Материалы с IETF P2PI Workshop: http://www.funchords.com/p2pi/ (чисто для смеху, там есть Position Paper of the RIAA - это очень смешно)
RRG on Loc/ID split
После прошлогоднего IAB Workshop on Routing and Addressing в списке рассылки RRG (Routing Research group) идет очень активная работа на предмет как намреорганизовать Рабкрин переделать архитектуру маршрутизации в Internet. Подходов там целая куча: LISP, Six/One, Ivip, TRRP и еще несколько. Останавливаться на них я не буду, отсылаю заинтересованных читателей к архиву maillist'а и соотвествующим статьям и драфтам.
На сессии RRG было (или только будет?) выступление Joel Halpern с очень правильной мыслью. Можно устроить разделение функций locator/identifier не внутри сетевого уровня, а между сетевым и транспортным уровнем: на сетевом locator, а на транспортном identifier. В принципе, идея не новая, но очень, по-моему, правильная. Пойдя по этому пути, можно избежать довольно опасных вещей, которые предлагаются в рамках того же LISP, например.
Презентация Joel Halpern: http://www.ietf.org/proceedings/08jul/slides/RRG-0.pdf
Несколько штучек, которые меня заинтересовали:
Virtual Aggregation
Некоторое время назад Paul Francis в grow@ietf рассказал про свою статью "Reducing FIB Size through Virtual Aggregation".
С тех пор он передумал и решил дополнить свой подход BGP-сигнализацией для некоторой автоматизации и, соотвественно, опубликовать свой драфт уже не в GROW, а в IDR. Что он и сделал в начале этого месяца, взяв в соавторы Xiaohu Xu из Huawei. В idr@ietf успели пообсуждать этот драфт немного, поэтому, скорее всего, надо ждать версии -01 в скором времени.
Суть предложенного подхода заключается в инжектировании довольно коротких префиксов (локальных для данной AS), и выкидывания из FIB (но не из RIB) префиксов более длинных. Если использовать правильную систему туннелей (например MPLS-туннелей), то это не приведет к циклам, но, естественно, может удлинить пути для трафика в данной AS. Статья показывает, что если выкидывать из FIB не все префиксы, а только "непопулярные", то можно достичь значительного сокращения объема FIB, не сильно ухудшив общую картину с оптимальностью путей трафика. Я в такой результат вполне верю: по словам коллеги из одного [довольно большого] оператора, на 120K префиксов уходит всего лишь около 1% трафика.
Кроме того, инжектирование покрывающих префиксов может помочь улучшить время сходимости. Здесь есть два фактора:
1) Покрывающий префикс распространяется независимо от специфичного и может служить своего рода fall back'ом для случая, когда next-hop специфичного префикса погиб. С несколькими одинаковыми префиксами обеспечить fallback труднее из-за того, что BGP-спикер анонсирует только лучший путь - это так называемая проблема path invisibility.
2) Маршрутизаторы, которые вбрасывают покрывающие префиксы, образуют уровень иерархии. Соответственно, как указал Robert Raszuk, само число роутеров, которые должны нести fallback пути, меньше. Плюс, если использовать BFD для быстрого обнаружения падения next-hop'ов, то BFD mesh серьезно уменьшается.
Надо сказать, в отношении BGP части у авторов получилась какая-то хуавейня, извините за выражение. Никакой особой автоматизации не получилось, а та, которая получилась, попросту опасна. Но это не отменяет ценности самого подхода, и, думается, что BGP часть поддается доработке.
Я эту конструкцию на прошлых выходных собрал в лабе. Работает (с некоторыми недочетами). Но получилось слишком сложно, чтобы рекомендовать это для реального внедрения прямо сегодня.
Текущая версия драфта: http://tools.ietf.org/html/draft-francis-idr-intra-va-00
Презентация на IETF72, кратко описывающая суть предложенного: http://www.ietf.org/proceedings/08jul/slides/idr-3.pdf
TANA
На этой встрече IETF запланирована BoF сессия TANA (Techniques for Advanced Networking Applications)
О чем речь? В одной из своих заметок я упоминал, что для peer-to-peer приложений пригодился бы новый транспортный протокол со специальным congestion control. Вот TANA именно про это. Цель в разработке алгоритма congestion control, который позволял бы p2p не мешать интерактивным задачам, но тем не менее эффективно утилизировал бы полосу, когда она не затребована другими приложениями. Насколько я понял, технология уже есть и используется в Bittorrent DNA.
BoF session по TANA будет 31-го июля. С нетерпением жду minutes.
TANA BoF agenda: http://www.ietf.org/proceedings/08jul/agenda/tana.txt
TANA Problem Statement: http://www.ietf.org/internet-drafts/draft-shalunov-tana-problem-statement-01.txt
Материалы с IETF P2PI Workshop: http://www.funchords.com/p2pi/ (чисто для смеху, там есть Position Paper of the RIAA - это очень смешно)
RRG on Loc/ID split
После прошлогоднего IAB Workshop on Routing and Addressing в списке рассылки RRG (Routing Research group) идет очень активная работа на предмет как нам
На сессии RRG было (или только будет?) выступление Joel Halpern с очень правильной мыслью. Можно устроить разделение функций locator/identifier не внутри сетевого уровня, а между сетевым и транспортным уровнем: на сетевом locator, а на транспортном identifier. В принципе, идея не новая, но очень, по-моему, правильная. Пойдя по этому пути, можно избежать довольно опасных вещей, которые предлагаются в рамках того же LISP, например.
Презентация Joel Halpern: http://www.ietf.org/proceedings/08jul/slides/RRG-0.pdf
К предыдущему посту. Еще немного keywords.
MUST+ Если вы это не реализуете, мы придем к вам с дубинкой и научим читать RFC.
MUST+- Надо реализовать эту фичу или по крайней мере сделать вид, что она реализована.
MUST-+ Мы в нерешительности между MUST и MUST NOT.
SHOULD+? Мы бы очень хотели, чтобы вы это реализовали, т.к. без этого все сломается. Но мы знаем, что вы затрахаетесь это делать.
MAY-- Если хотите, вы можете это сделать, но ваши пользователи вас проклянут. И не говорите, что мы вас не предупреждали.
Дополняйте. Потом переведем и засабмитим как настоящий первоапрельский RFC.
MUST+ Если вы это не реализуете, мы придем к вам с дубинкой и научим читать RFC.
MUST+- Надо реализовать эту фичу или по крайней мере сделать вид, что она реализована.
MUST-+ Мы в нерешительности между MUST и MUST NOT.
SHOULD+? Мы бы очень хотели, чтобы вы это реализовали, т.к. без этого все сломается. Но мы знаем, что вы затрахаетесь это делать.
MAY-- Если хотите, вы можете это сделать, но ваши пользователи вас проклянут. И не говорите, что мы вас не предупреждали.
Дополняйте. Потом переведем и засабмитим как настоящий первоапрельский RFC.
Мне тут на днях хороший человек 
lesham подогнал свежачок (за что ему отдельное спасибо) - материалы с конференции MPLS 2007: http://www.isocore.com/mpls2007/cd/MPLS2007Program.htm .
Я пока еще не все там прочитал и обдумал, поэтому остановлюсь только на нескольких презентациях.
lesham подогнал свежачок (за что ему отдельное спасибо) - материалы с конференции MPLS 2007: http://www.isocore.com/mpls2007/cd/MPLSЯ пока еще не все там прочитал и обдумал, поэтому остановлюсь только на нескольких презентациях.
Continue reading MPLS 2007.
Что-то давненько я не блогал длинной и скучной нудятины про сети. Видимо, работа удовлетворяет потребности в писательстве ;)
Мимо меня раз в несколько месяцев пробегает очередная версия любопытного драфта. Я все порываюсь поиграться и заблогать, но все как-то было не до того. Наконец, дошли руки. Драфтик этот в девичестве назывался draft-decraene-mpls-ldp-interarea, а теперь его приняли как workgroup документ в MPLS WG и теперь он называется draft-ietf-mpls-ldp-interarea.
О чем речь?
Мимо меня раз в несколько месяцев пробегает очередная версия любопытного драфта. Я все порываюсь поиграться и заблогать, но все как-то было не до того. Наконец, дошли руки. Драфтик этот в девичестве назывался draft-decraene-mpls-ldp-interarea, а теперь его приняли как workgroup документ в MPLS WG и теперь он называется draft-ietf-mpls-ldp-interarea.
О чем речь?
Continue reading Interarea LDP.
Коллега подогнал драфтик.
Не знаю, как я его прощелкал - седьмая версия драфтика все-таки, к тому
же выходит в WG, список рассылки я, хоть и по остаточному принципу, но
читаю. Оказывается, оно уже выдвигалось на proposed standard в 6-й
версии, но решили немного доточить и на днях вышла новая, 7-я версия.
Это очень, очень хороший драфтик. Не то, что мне на самом деле нравится решение, но это шаг в очень правильном направлении. Я давно ждал чего-то на эту тему.
Это очень, очень хороший драфтик. Не то, что мне на самом деле нравится решение, но это шаг в очень правильном направлении. Я давно ждал чего-то на эту тему.
Continue reading Так!.
