(no subject)
Мне тут на днях хороший человек lesham подогнал свежачок (за что ему отдельное спасибо) - материалы с конференции MPLS 2007: http://www.isocore.com/mpls2007/cd/MPLS2007Program.htm.
Я пока еще не все там прочитал и обдумал, поэтому остановлюсь только на нескольких презентациях.
Некоторое время назад я писал про draft-ietf-mpls-ldp-interarea. С тех пор в этой области был некоторый прогресс. Циска выступила с контр-драфтом. Идея там очень простая: агрегирующий ABR посылает только одну метку на агрегированный префикс, но при этом не использует PHP, а деагрегирующие метки, необходимые для построения непрерывных LSP, вычисляются некоторым общим для ABR и ingress PE алгоритмом, при этом метка агрегированного префикса и деагрегирующая метка стекируются на пути от ingress PE до агрегирующего ABR и, соотвественно, никому по пути от ingress PE до агрегирующего ABR деагрегирующая метка неизвестна. Симпатично. Проблема решена?
Презентация George Swallow (автора draft-swallow-mpls-aggregated-fec) как раз посвящена проблемам, возникающим при таком подходе, и развитию его идеи с тем чтобы избежать этих проблем.
В чем засада при чистом draft-swallow-mpls-aggregated-fec? В BGP next hop tracking. Если мы все сагрегируем: и next-hop адреса, и метки, соотвествующие этим адресам, то единственным способом определить падение дальнего PE будет BGP hold timer - а это очень и очень небыстро.
Как объехать? Swallow предлагает подход "Summarized route, detailed reachability" (SRDR). Т.е. IGP у нас будет агрегировать маршрут, но при этом сообщать достижимость отдельных адресов внутри агрегированного префикса, анонсируя битовый вектор размером 2^(32 - длина агрегированного префикса). Поскольку драфта по SRDR еще нет (по крайней мере я не нашел), можно только предполагать, как именно это будет реализованно. Логично предположить, что для OSPF это будет LSA type 11 (inter-area opaque), а для IS-IS - просто отдельный TLV.
Джунипер тоже не стоял на месте, и Kireeti Kompella в своей презентации рассказал про развитие draft-ietf-mpls-ldp-interarea. У draft-ietf-mpls-ldp-interarea нет проблемы с NHT, как у draft-swallow-mpls-aggregated-fec - в случае draft-ietf-mpls-ldp-interarea падение egress PE можно определить по пропаданию его LDP метки, но есть другая проблема - там уменьшается объем IGP, но объем LDP-сигнализации и объем LIB/LFIB остается тем же.
Что предлагается? Hierarchical LDP. В Label Mapping Message добавить TLV того же самого формата, что и сам Label Mapping Message. Внешний label mapping соотвествует агрегированному префиксу, а метки во вложенных деагрегированным. Метки во внешнем Label Mapping Message и внутреннем стекируются. Соотвественно, этот внутренний label mapping нужен только ingress PE и, естественно, самому ABR. Тоже красиво. На это опять таки нет драфта, поэтому о некоторых деталях нужно догадываться.
Теперь надо решить, какая схема лучше. Я, надо сказать, в задумчивости. "Все такое вкусное". Обе решают проблему масштабирования без привлечения схемы с сомнительной управляемостью, которую я в подробностях описывал в предыдущем посте на эту тему.
Не претендуя на полноту, попробую сравнить.
1) Interop с существующим положением вещей.
Цискина схема:
Потребуется включение opaque LSA в сетях с OSPF. Поскольку речь о LDP сетях, то это новая фича - такие сети раньше не зависили от opaque LSA. А поскольку речь идет об inter-area opaque, то обязательно найдется какой-нибудь говновендор, у которого это сломано - в нынешних сетях inter-area opaque нет, соотвественно, кое-кто мог и забить. В случае IS-IS надо организовывать leaking SRDR TLVs в level-1 области. Тут больших засад не предвидится, L1/L2 роутеры все равно будут обязаны поддерживать SRDR, а остальные уже давно научились правильно обходиться с unknown TLV в IS-IS'ных LSP.
Джуниперская схема:
LDP предусматривает расширяемость и транспорт ранее неизвестных TLV с помощью механизма U- и F-битов. Конечно, всегда может найтись дятел, который сломает и это, но вероятность мала, ибо это U- и F-биты - интегральная часть спецификации LDP.
2) Потенциальные проблемы с размерами протокольных сообщений.
Цискина схема:
Максимальный размер OSPF LSA - 64K. Для достаточно длинных агрегированных префиксов SRDR бит-вектора будут не очень длинными, все может и поместиться. А если мы таки доживем до IPv6? Бит-вектор длиной 2^64 бит, например, - это слишком. Можно избежать этих проблем аккуратным назначением адресов лупбекам роутеров и выключением SRDR для агрегированных префиксов, соотвествующим адресам линков. Для IS-IS почти все то же самое, но там есть механизмы борьбы с очень длинными LSP.
Джуниперская схема:
Максимальная длина LDP Label Mapping Message - тоже 64K, но здесь не надо перечислять все адреса в агрегируемом диапазоне даже в виде битового вектора. Пусть средняя длина обычного Label Mapping Message - байтов 40. Это с запасом: 8 байт на заголовок, 16 (или 12? не помню) - на FEC, 8 на метку. Ну, с IPv6 длина FEC TLV будет побольше. Т.е. даже если в области 1000 роутеров, все поместится.
3) Общая "правильность".
Цискина схема:
Мысль о том, что routing и reachability - разные вещи, очень правильная. И, в принципе, SRDR механизм может найти и другие применения. Самое простое - обычный IP-роутинг без какого-либо MPLS с агрегацией на границах областей и BGP next-hop tracking. Если подумать, можно придумать еще. Т.е. полезность этой схемы не исчерпывается решением проблемы масштабирования LDP.
Джуниперская схема:
Здесь хорошо то, что вся информация в одном месте - в LDP. Нет сценариев, когда LDP говорит одно, а SRDR механизм говорит другое. Плюс LSA/LSP фладятся периодически, а LDP сообщения ходят по TCP и при liberal retention живут, пока живет adjacency. Цискина схема выглядит несколько более хрупкой.
Итого, на мой взгляд, джуниперское предложние несколько лучше. А вы, коллеги, как думаете?
Немного в сторону. Несколько слов в презентации Luca Martini пересекаются с этой темой, хотя презентация совсем о другом. "Keep the MPLS implementation simple, PW is the access, L3VPN in the edge/core for services." В этом есть резон не только с точки зрения сложности сети, о чем сама презентация, но и с точки зрения масштабируемости IGP и LDP. Если выделить домены, из которых выносить трафик псевдопроводами до узлов, на которых живут реальные сервисы, но эти домены вполне могут иметь совершенно отдельные IGP и LDP.
А сама по себе презентация Martini тоже интересная. Имеет прямое отношение к хайпу о PBT. Советую прочитать.
Все на сегодня. Выговорился. Пойду пивка приму.
Я пока еще не все там прочитал и обдумал, поэтому остановлюсь только на нескольких презентациях.
Некоторое время назад я писал про draft-ietf-mpls-ldp-interarea. С тех пор в этой области был некоторый прогресс. Циска выступила с контр-драфтом. Идея там очень простая: агрегирующий ABR посылает только одну метку на агрегированный префикс, но при этом не использует PHP, а деагрегирующие метки, необходимые для построения непрерывных LSP, вычисляются некоторым общим для ABR и ingress PE алгоритмом, при этом метка агрегированного префикса и деагрегирующая метка стекируются на пути от ingress PE до агрегирующего ABR и, соотвественно, никому по пути от ingress PE до агрегирующего ABR деагрегирующая метка неизвестна. Симпатично. Проблема решена?
Презентация George Swallow (автора draft-swallow-mpls-aggregated-fec) как раз посвящена проблемам, возникающим при таком подходе, и развитию его идеи с тем чтобы избежать этих проблем.
В чем засада при чистом draft-swallow-mpls-aggregated-fec? В BGP next hop tracking. Если мы все сагрегируем: и next-hop адреса, и метки, соотвествующие этим адресам, то единственным способом определить падение дальнего PE будет BGP hold timer - а это очень и очень небыстро.
Как объехать? Swallow предлагает подход "Summarized route, detailed reachability" (SRDR). Т.е. IGP у нас будет агрегировать маршрут, но при этом сообщать достижимость отдельных адресов внутри агрегированного префикса, анонсируя битовый вектор размером 2^(32 - длина агрегированного префикса). Поскольку драфта по SRDR еще нет (по крайней мере я не нашел), можно только предполагать, как именно это будет реализованно. Логично предположить, что для OSPF это будет LSA type 11 (inter-area opaque), а для IS-IS - просто отдельный TLV.
Джунипер тоже не стоял на месте, и Kireeti Kompella в своей презентации рассказал про развитие draft-ietf-mpls-ldp-interarea. У draft-ietf-mpls-ldp-interarea нет проблемы с NHT, как у draft-swallow-mpls-aggregated-fec - в случае draft-ietf-mpls-ldp-interarea падение egress PE можно определить по пропаданию его LDP метки, но есть другая проблема - там уменьшается объем IGP, но объем LDP-сигнализации и объем LIB/LFIB остается тем же.
Что предлагается? Hierarchical LDP. В Label Mapping Message добавить TLV того же самого формата, что и сам Label Mapping Message. Внешний label mapping соотвествует агрегированному префиксу, а метки во вложенных деагрегированным. Метки во внешнем Label Mapping Message и внутреннем стекируются. Соотвественно, этот внутренний label mapping нужен только ingress PE и, естественно, самому ABR. Тоже красиво. На это опять таки нет драфта, поэтому о некоторых деталях нужно догадываться.
Теперь надо решить, какая схема лучше. Я, надо сказать, в задумчивости. "Все такое вкусное". Обе решают проблему масштабирования без привлечения схемы с сомнительной управляемостью, которую я в подробностях описывал в предыдущем посте на эту тему.
Не претендуя на полноту, попробую сравнить.
1) Interop с существующим положением вещей.
Цискина схема:
Потребуется включение opaque LSA в сетях с OSPF. Поскольку речь о LDP сетях, то это новая фича - такие сети раньше не зависили от opaque LSA. А поскольку речь идет об inter-area opaque, то обязательно найдется какой-нибудь говновендор, у которого это сломано - в нынешних сетях inter-area opaque нет, соотвественно, кое-кто мог и забить. В случае IS-IS надо организовывать leaking SRDR TLVs в level-1 области. Тут больших засад не предвидится, L1/L2 роутеры все равно будут обязаны поддерживать SRDR, а остальные уже давно научились правильно обходиться с unknown TLV в IS-IS'ных LSP.
Джуниперская схема:
LDP предусматривает расширяемость и транспорт ранее неизвестных TLV с помощью механизма U- и F-битов. Конечно, всегда может найтись дятел, который сломает и это, но вероятность мала, ибо это U- и F-биты - интегральная часть спецификации LDP.
2) Потенциальные проблемы с размерами протокольных сообщений.
Цискина схема:
Максимальный размер OSPF LSA - 64K. Для достаточно длинных агрегированных префиксов SRDR бит-вектора будут не очень длинными, все может и поместиться. А если мы таки доживем до IPv6? Бит-вектор длиной 2^64 бит, например, - это слишком. Можно избежать этих проблем аккуратным назначением адресов лупбекам роутеров и выключением SRDR для агрегированных префиксов, соотвествующим адресам линков. Для IS-IS почти все то же самое, но там есть механизмы борьбы с очень длинными LSP.
Джуниперская схема:
Максимальная длина LDP Label Mapping Message - тоже 64K, но здесь не надо перечислять все адреса в агрегируемом диапазоне даже в виде битового вектора. Пусть средняя длина обычного Label Mapping Message - байтов 40. Это с запасом: 8 байт на заголовок, 16 (или 12? не помню) - на FEC, 8 на метку. Ну, с IPv6 длина FEC TLV будет побольше. Т.е. даже если в области 1000 роутеров, все поместится.
3) Общая "правильность".
Цискина схема:
Мысль о том, что routing и reachability - разные вещи, очень правильная. И, в принципе, SRDR механизм может найти и другие применения. Самое простое - обычный IP-роутинг без какого-либо MPLS с агрегацией на границах областей и BGP next-hop tracking. Если подумать, можно придумать еще. Т.е. полезность этой схемы не исчерпывается решением проблемы масштабирования LDP.
Джуниперская схема:
Здесь хорошо то, что вся информация в одном месте - в LDP. Нет сценариев, когда LDP говорит одно, а SRDR механизм говорит другое. Плюс LSA/LSP фладятся периодически, а LDP сообщения ходят по TCP и при liberal retention живут, пока живет adjacency. Цискина схема выглядит несколько более хрупкой.
Итого, на мой взгляд, джуниперское предложние несколько лучше. А вы, коллеги, как думаете?
Немного в сторону. Несколько слов в презентации Luca Martini пересекаются с этой темой, хотя презентация совсем о другом. "Keep the MPLS implementation simple, PW is the access, L3VPN in the edge/core for services." В этом есть резон не только с точки зрения сложности сети, о чем сама презентация, но и с точки зрения масштабируемости IGP и LDP. Если выделить домены, из которых выносить трафик псевдопроводами до узлов, на которых живут реальные сервисы, но эти домены вполне могут иметь совершенно отдельные IGP и LDP.
А сама по себе презентация Martini тоже интересная. Имеет прямое отношение к хайпу о PBT. Советую прочитать.
Все на сегодня. Выговорился. Пойду пивка приму.