Досужее

Вечер пятницы - время для досужих мечтаний. Вот и мне после вкусного ужина со стаканчиком пива слегка подумалось.

Вот какая есть штука: между работой data plane и работой control/management plane сетевого элемента есть существенный концептуальный разрыв.

Если опустить некоторые детали и упростить, то control/management plane оперирует понятиями логического интерфейса, адреса, маршрута, т.д., а на data plane ничего подобного нет, там есть физическая веревка, несколько таблиц и несколько простых операций: lookup в той или иной таблице (с возможным ее пополнением) по одному или нескольким полям, переписывание части пакета, передача его в физическую веревку или опять на lookup в другой таблице. А все эти subinterfaces, pseudowires, vlans, vrfs и прочая, и прочая, в терминах которых мы конфигурим наши железки, - их на самом деле нет, это интерфейс к реальным механизмам форвардинга, абстракция, предоставленная нам производителем роутера.

Хорошо это или плохо? С одной стороны это хорошо, поскольку необходимо, т.к. те же протоколы маршрутизации оперируют теми же понятиями интерфейса, адреса, маршрута. С другой стороны, иногда эти выразительные средства не позволяют добиться желаемого поведения сетевого элемента, или позволяют ценой немыслимых извращений, или насколько криво отображаются в примитивные средства data plane, что это приводит к самым неочевидным эффектами, из которых потеря в производительность не самый страшный, хотя и самый распространенный. Leaky abstraction и abstraction inversion во всей своей красе.

До относительно недавних пор все двигалось в одну сторону - когда кастомеры били ногами вендора, вендор вводил фичу, расширяя и усложняя control plane'овую абстракцию, но все же оставаясь в ее рамках. Так и появлялись всякие "this over that support", "whatever scalability enhancements", "virtual something", которыми пестрят release notes каждой новой версии софта. Это оптимизации, это поддержанные на официальном уровне accidental features, это закрытие зияющих прорех абстракции. И все это ad hoc, все лоскутно, все реактивно, а не проактивно.

Однако, недавно циску (у некоторых других вендоров есть, кажется, похожие вещи) это достало, и она сделала EVC (Ethernet Virtual Circuit). Это конфигурационный механизм, который позволяет определять поведение непосредственно в терминах match-rewrite-forward. По .1q'шным тэгам, но это уже хорошо. Этот EVC - большой рулез. Это гибкий механизм, который позволяет делать более естественно, то что можно было делать раньше с помощью субинтерфейсов, и делать новые, ранее невозможные вещи. Правильная, очень правильная вещь.

Но этого мало. Я хочу распространения похожего механизма на все data plane'овые операции. Это очень облегчило бы жизнь. Сразу исчезли бы глупые и крайне неочевидные хаки типа global keyword для статических маршрутов в VRF, или совершенно ужасного GRT prefix import into a VRF. Можно было бы строить интересные и полезные наложенные топологии со смешанным L2/L3 форвардингом (ох, у фанатов модели OSI сейчас будет инфаркт, хехе).

Я прекрасно отдаю себе отчет, что возможности разных платформ очень разные, и такой механизм был бы очень тесно привязан к платформе. Ну и что. Можно сделать это платформозависимо, можно придумать что-то вроде MQC - на самом деле, если немного расширить PBR, скомбинировать его с EVC, то получится похоже на то, что я хочу.