Можно было бы и поподробнее рассказать, или сосредоточиться на чём-то конкретном, а так как-то сумбурно получилось.
Но ничего тут нового и особо интересного нет.
У cisco, например, есть REP, который тоже предназначен для построения высокодоступных кольцевых топологий, и который так же может работать в открытых сегментах.
Да и есть ещё Ethernet Ring Protection Switching, который поддерживается Juniper'овскими коммутаторами…
strongswan.conf выглядит немного странно: две секции charon (одна лишняя) и секция pluto (в 5ой версии strongswan этого демона уже нет, а его функциональность (IKEv1) интегрирована в charon).
Мне кажется, что стоит упомянуть, что данные проверки относятся к так называемым «позиционным» проверкам, т.е. они совпадают не с текстом, а с позицией в тексте. При этом текст не «поглощается», что позволяет матчить его другой частью регулярного выражения.
А Вы сами-то осилили Кнута? Есть хорошая шутка: «Программисты делятся на две категории: на тех, кто осилил Кнута, и на тех, кто говорит правду». Для школьников материал непосильный хотя бы из-за того, что для начала нужно знать на очень хорошем уровне дискретную математику.
Официальные источники утверждают, что в качестве роутсервера используется программный маршрутизатор BIRD. А до этого использовалась Quagga. И так на многих площадках обмена трафиком.
На то он и коммутатор — попробуйте в него фуллвью влить и посмотреть, как он загнётся, так как пересылка пакета требует больших мозгов, нежели коммутация (которая выполняется на ASIC, поэтому и цпу мощный не нужен).
Может Вы невнимательно читали, но контроллеру не нужно маршрутизировать 720 гб/c, а достаточно выполнить маршрутизацию для первого и единственного пакета из потока, после чего все остальные кадры, принадлежащие этому потоку будут коммутироваться теми же ASIC на всех устройствах сети на скорости порта. И не нужно Вам будет на каждой циске по «модному супервайзеру».
Ну одно дело передать пакет с информацией о новом потоке контроллеру и получить ответ, а другое дело ждать, пока каждый из маршрутизаторов на пути следования потока будет решать, сможет ли он выделить необходимые ресурсы, и пересылать RSVP пакеты дальше.
На счёт мозгов контроллера — их всего несколько штук надо будет на сеть с учётом резервирования. Да и для контроллера не нужен будет суперкомпьютер. А в данный момент если у вас интеллектуальная сеть, то каждое устройство должно обладать не хилыми такими мозгами и поддерживать кучу фич.
Может мои ответы сумбурны, но Вы уж извините меня.
Естественно, про единую точку отказа тоже люди подумали, поэтому контроллер может быть зарезервирован (несколько контроллеров с синхронизированными данными, находящихся в разных частях сети). По поводу пограничных маршрутизаторов — ничего не могу сказать конкретного, но мне кажется, что и их интеллектуальные функции (вычисление маршрутов, фильтрация трафика и решение о пересылке) можно с успехом возложить на контроллер.
Даже в сетях MPLS всё же каждое устройство принимает решение более-менее самостоятельно, с учётом известной ему информации на основе топологии, полученной от IGP. В опенфлоу весь интеллект не размазан по всей сети, а сосредоточен в одном месте, благодаря чему решения принимаются с учётом цельной картиной. Отсюда проистекает несколько теоретических преимуществ, начиная с моментальной сходимости (как только обнаружен сбойный участок), более интеллектуальном управлением ресурсами (нет необходимости в RSVP, с помощью которого резервируется ресурсы сети, а это всё-таки время), более низким требованиям к мозгам отдельных устройств и тому подобные плюшки. Имхо, как-то так.
Про обмен значений переменных с помощь исключающего или уже везде, где можно и нельзя обсудили, а вывод один — никогда не используйте этот метод. Тоже самое и с рекурсивными функциями — используйте с крайней осторожностью, если конечно, не на функциональных языках пишете. Имхо, однострочники не нужны — оформляйте код так, чтобы его можно было прочитать и понять без проблем.
Но ничего тут нового и особо интересного нет.
У cisco, например, есть REP, который тоже предназначен для построения высокодоступных кольцевых топологий, и который так же может работать в открытых сегментах.
Да и есть ещё Ethernet Ring Protection Switching, который поддерживается Juniper'овскими коммутаторами…
Может Вы невнимательно читали, но контроллеру не нужно маршрутизировать 720 гб/c, а достаточно выполнить маршрутизацию для первого и единственного пакета из потока, после чего все остальные кадры, принадлежащие этому потоку будут коммутироваться теми же ASIC на всех устройствах сети на скорости порта. И не нужно Вам будет на каждой циске по «модному супервайзеру».
На счёт мозгов контроллера — их всего несколько штук надо будет на сеть с учётом резервирования. Да и для контроллера не нужен будет суперкомпьютер. А в данный момент если у вас интеллектуальная сеть, то каждое устройство должно обладать не хилыми такими мозгами и поддерживать кучу фич.
Может мои ответы сумбурны, но Вы уж извините меня.