IETF72
На этой неделе в Дублине проходит очередная встреча 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
0 TrackBacks
Listed below are links to blogs that reference this entry: IETF72.
TrackBack URL for this entry: http://net-geek.org/cgi-bin/mt/mt-tb.cgi/274
на тему LISP в IP Journal (март 2008) статья нормальная была.
Прочитал. Мeyer обошел стороной очень важный вопрос. Вопрос кешей и поведения системы при отказах ITR. Эту булочку мы уже жевали, на самом деле, в виде fast switching например, но тут все еще хуже.
Естественно, что эта проблема возникает при любом разделении id/loc - identifier надо как-то отображать на locator, а держать полную карту отображения везде окажется, скорее всего, невозможным. Это все заработает только если функцию отображения мы сможет масшатбировать, а масштабировать ее получится разве что за счет распределенности, в идеале до оконечного устройства.