Shortest Path Bridging (SPB)

Это иногда может пригодиться. Мне бы тоже хотелось иметь SPB.

+1 за SPB/Trill и даже за LISP. Что касается LISP, технически это отличная идея, и я бы с удовольствием её увидел в деле, но... LISP уже давно известен как аббревиатура для уважаемого языка программирования "List Processing". Почему, зачем им пришлось давать этому новое значение?

Разделение местоположения и идентичности было бы просто супер, привнесло бы в IP что-то вроде возможностей SS7, но неужели им так уж надо было назвать это LISP? Раз уж заговорили, как насчёт нового протокола следующего поколения, похожего на FTP, под названием Formidable Transfer (сокращённо FORTRAN)? Или может новую альтернативу OpenFlow под именем Just Another Virtual Architecture (то есть JAVA)? –Эрик

СПБ Сейчас!

Вы можете использовать почти все возможности SPB прямо сейчас, просто внедрив MPLS с VPLS и/или VRF. Поэтому сомневаюсь, что Mikrotik когда-либо добавит SPB, ведь похожий сервис абстракции уровня 2/3 уже доступен. Но введение IS-IS и MPLS-FRR было бы очень кстати.

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

Согласен. MPLS работает, но приходится столкнуться с кучей проблем, чтобы понять, что можно делать, а что нет, и находить обходы. Это точно не что-то бесшовное. Кроме того, там слой на слое, и из-за этого обучение техников становится сложнее. SPB — это мост с более продвинутым логированием в самой базовой версии, который использует IS-IS на втором уровне, что по сути просто “включил и работает” в самой простой реализации. Для *ISP это в основном преднастройка, а потом добавление дополнительной метрики на резервные или медленные интерфейсы. Конечно, можно сделать и более сложные решения, но, на мой взгляд, самая простая схема подходит для 90% случаев и реально помогла бы многим операторам.

Это могло бы помочь расширить технический пул обслуживающего персонала, без сомнений. Я, например, могу обучить кого-то смотреть логи SPB и находить проблемы, а главное — они смогут решать вопросы с линками, не парясь о правильных IP-адресах и VLANах. Мне кажется, SPB — лучший и более широко поддерживаемый протокол, поэтому я выбрал бы его вместо TRILL или LISP, тем более что он уже поддерживается на железе некоторых моделей mikrotik с чипами Marvell.

По моему мнению, SPB — самая простая вещь для внедрения на Mikrotik на подходящем оборудовании, потому что, в основном, это просто использование встроенных возможностей железа с фронтендом поверх. Единственная настоящая проблема — если придется делать программную реализацию для неподдерживаемых устройств. Вот почему я еще прошу SRv6. IS-IS + IPv6 + SRv6 тоже очень просто реализовать, и это дает возможность для туннелирования и управления трафиком.