Последний раз про Cisco

[furrry]

Кстати. Мое мнение о компании Cisco сильно улучшилось после демонстрации того, что у них теперь умеет OnePK (если кто не в курсе - они-таки сделали API к устройствам - C/Java/Python).
Общение с control plane - это понятно и ожидаемо. А вот что реально круто - API позволяет делать packet injection into forwarding plane. А жизнь-то налаживается!

Comments

[ezdivala.livejournal.com]

Ну отношение двоякое.
С одной стороны хорошо, а с другой мы все (которые и CLI-то с трудом) останемся без работы.

[furry.livejournal.com]

Дорогая, ну что Вы такое говорите, право! Мы же с Вами прекрасно понимаем, что из каждых 100 заработанных долларов - 1 доллар нам заплатили за то, что мы махнули молотком набрали что-то в CLI, а 99 - за то, что знали куда бить что именно и когда набирать!

[ezdivala.livejournal.com]

нет, ну мы с Вами-то, конечно, сидим в центре Вселенной и усилием мысли перенаправляем потоки битов и байтов, повелеваем электромагнитными волнами одним взглядом. Я же сейчас не столько про нас, сколько про развитие индустрии вообще. Как вообще будут выглядеть advanced services в будущем, как это вписывается в модель заказчик-партнер-вендор, как программисты вообще собираются что-то писать под это железо? И открыто это продавать? Это или инженеров нужно учить Питону (что в случае со мной вообще затея интересная) или программистов - семиуровневой модели.
Очевидно, что за SDN будущее, и вообще надо было так с самого начала все строить, но вот с практической точки зрения - многонеясного(с).
Говорят, уже есть один готовый деплоймент как всегда в Bay Area, вот ну очень бы интересно было глянуть.

А вообще тема на редкость занимательная.

[theholm.livejournal.com]

Ну OpenPK это не совсем SDN. Вот Juniper уже давно с OpenFlow забавляется, но пока ничего работоспособного не представила. А учится питону придется всем. Ну или в GUI мышкой возить.

[bugware.livejournal.com]

Как прямо тут сказано у Евгении Борисовны: "C/Java/Python".
Так что учиться питону придётся не всем.

[cdplayer.livejournal.com]

> Говорят, уже есть один готовый деплоймент

Как-то маловато, за полтора-то года существования onePK в открытом пространстве.

> Как вообще будут выглядеть advanced services в будущем

адванцед сервизес будут вокруг дизайна, запуска, и отладки application policies, которые будут рулить различными компутерными (в т.ч., сетевыми) ресурсами для важных бизнесу приложений.

Также см. OpenDaylight (только что первая версия вышла), хотя там ещё темна вода во облацех - полетит, или таки загнётся.

[bugware.livejournal.com]

Как будет выглядеть? Трава будет менее зелёной. Мужики скучнее. И т.д.
В IOS-ах уже Ричард знает сколько времени есть встроенный тикль.
А пенсионеры всё никак не дождутся, когда ж их нанимать-то начнут на тикле сетекод фигачить.

Песню про то, что "скоро нам, граждане, крышка" я слыхал ещё когда циска SDМ выпустила: "вот, кастомеры теперь будут теребить гуй мозолистой рукой, а мы все умрём от голода..."

"За SDN будущее"
Большой шкаф, большие шкафы с тупыми терминалами, персоналки, клиент-сервера, тонкие клиенты, облака.
Ты уверена, что на облаках всё закончится и не будет никакого "золото, суд, Сибирь"?
(Домашнее задание. Дано: "статика... дистанс вектор ... mpls ... sdn". Требуется: заполнить пробелы в моём образовании.)

С практической точки зрения мне представляется одна простая штука.
Если у тебя есть 5-6 роутеров, то даже мне ты сумеешь наглядно продемонстрировать, что бутерброд вкуснее кусать OSPF-ом, BGP и прочим MPLS-ом на язык. Или тонкую фекальную нотку в букете RIP/IGRP...
C SDN получается или "ну и чем это лучше X, Y или Z?" или же тысячи девайсов (каким-то магическим образом все с последней версией софта), кубокилометры трафика и мегатонны электричества. И тут приходится или адмиралов вернуть на воду или матросам "показать полную карту". И то и другое как правило "вообще затея интересная".

[furry.livejournal.com]

Я тебя обожаю!

P.S. Но "мужики скучнее" - этого нам не надо!

[furry.livejournal.com]

Во-первых, заметим, что это не я первая произнесла SDN. По правде сказать, я бы вообще предпочла не упоминать эту аббревиатуру. Я вот тут как-то полчаса общалась с коллегой - без какого-либо намека на понимание между нами. В конце концов выяснилось, что когда я произношу "UPS" - я имею ввиду службу доставки. А он - источник безперебойного питания. Вот с SDN примерно так же. Одни под SDN понимают Python API к маршрутизаторам, другие - PCE, а третьи - OpenFlow.

Я, кстати, поняла, что в моей реальности инженеры все на чем-то в той или иной степени пишут, и я еще самая ленивая (меня на мою позицию полтора года не брали, потому что я на питоне отказывалась писать) - но допускаю, что это не везде так. В модель "заказчик - вендор - партнер" это вписывается как и раньше. Только вместо того, чтобы рассказывать, какие LSP и где настраивать - provision всего этого на контроллерах. Тебя же не удивляет, что теперь вместо настройки отдельных точек доступа - мышкой возят в WLC, или как оно там назыается.

[fuflolog.livejournal.com]

У большинства точек доступа примерно одинаковый конфиг, поэтому-то его и можно накликать мышью. А вот порты на свитче накликать я бы даже и пробовать не стал.

Provisioning система, вообще говоря, очень нужна, но если ее делать подо все возможные случаи сразу, то это будет фактически еще один гуй.

Поэтому имеет смысл сузить задачу, затем под нее сделать шаблон конфигурации, в этом шаблоне выделить поля, где будет лежать все, что изменяется от железки к железке, ну и дальше понятно - значения полей храним в БД и генерим полную конфигурацию для конкретной железки, когда надо.

[lesnix.livejournal.com]

> Очевидно, что за SDN будущее

А мне, вот, например, неочевидно.
Не могу не воткнуть сюда ссылку на прекрасное, на мой взгляд, мероприятие с участием dbg:
http://tech.yandex.ru/events/science-seminars/SDN-21nov/ про этот самый SDN.