Может быть оправдано только в очень специфических случаях. То что я описывал справедливо не только для uint8, для uint32. Предположу, что выйгрыш ещё ниже будет.
Вы затрагиваете очень интересный вопрос, и в целом верно говорите, все апстримные проекты, на которых лежат OPNFV и Openstack, постоянно развиваются. Дилемма — принять их как есть, динамичными или пересоздать в виде чего-то статического и неизменяемого — в таких проектах, заточенных под совместимость и производительность, решается именно первым способом. В качестве медиатора разных интерфейсов используется не «обвязка в виде скриптов», а более продвинутый слой Middleware. Рискну предположить, что в OPNFV всё сращивается через MOM, входящий в опенстэк — rabbitmq, либо что-то ему подобное.
Мда, нестыковочка. MPLS TE я привёл в качестве примера сложного Control Plane — это самый навороченный функционал, который можно встретить на CE-роутере. Притом скорее нетипичный для CE, а больше типичный для P/PE, такая абсурдная крайность, которая почти не встречается.
— Можно ли предоставить виртуальный CPE (=Business CE) с поддержкой MPLS? — можно, притом даже в нынешних дизайнах Virtualized Multitenant Datacenter это не проблема. Например, на платформе amazon доступен Brocade Vyatta — это лишь один из линейки.
— Возможно ли использовать преимущества MPLS в таком режиме? — Скорее нет, т.к. MPLS сервисы требуют сквозной сигнализации меток. Для MPLS L3 VPN технологически возможны подобные схемы: Inter-AS-VPN, Carrier-supporting-Carrier, которые позволяют несколько вариантов пиринга с провайдером или через провайдера для сохранения сквозной сигнализации меток — но я не слышал о том, чтобы кто-то такой вариант применял в облаке — он всё-таки сложноват для оператора и плохо масштабируем. А для MPLS TE такого сквозного механизма нет вообще. К тому же, Service Chaining NFV предполагает простейшую топологию — линейную, а Multi-Tier Virtual Datacenter облака — тоже самую простейшую иерархию Tier-ов (или зон) — так что нет даже задачи, для решения которой можно было бы применять MPLS TE.
— Если для лабораторных задач, стэйджинга, то вполне возможно пириться виртуальными роутерами и в облачке внутри одного vDC (они должны быть l2-adjacent), также можно входить в этот домен средствами туннелирования снаружи. Возможна даже связь с реальной сетью или другой лабой средствами GRE tunneling, и пиринга по всем протоколам внутри таких туннелей.
Sptsh, вопросов эта технология оставляет, действительно, очень много. Но на названные Вами — имею что сказать.
Риски и затраты мне видятся не такими уж большими — точка входа для решения на несколько десятков Gbps (а в российских условиях это несколько десятков тысяч broadband-абонентов или сотни тысяч мобильных), лежит где-то в масштабах пары десятков серверов весьма средней конфигурации и пары недорогих 10GE-коммутаторов. Внедряться NFV также может постепенно — например, дополнительная услуга (скажем, родительский контроль и антивирус от какого-нибудь новго, альтернативного поставщика) может быть развёрнута поверх NFV, притом все остальные компоненты остаются legacy.
Что касается MPLS и NFV, то эти технологии пересекаются, как я вижу, в двух плоскостях:
1. MPLS традиционно используется на магистральной сети и сети агрегации с целью изоляции сервисов и упрощения форвардинга. Если NFV-сервис должен иметь продолжение в остальных доменах операторской сети — условно говоря, VRF/PW на границе сети, соответствующий MPLS FEC на сети ядра, PW на сети агрегации, VLAN на сети доступа — что угодно — то оркестратор, которому даётся команда построить сервис, должен внести соответствующие изменения во всех доменах: в ЦОДе (NFVI) и на legacy-сети. Если сервис требует изменений на MPLS-инфраструктуре, то это делает оркестратор, и для NFV-домена всё оказывается абстрактно. NFV ничего может не знать про MPLS и вланы на сети доступа, а сети доступа и агрегации могут ничего не знать про NFV.
2. MPLS может использоваться внутри NFV домена (внутри ЦОД, между хостами) как способ маркировки, как средство сегментации для service-chaining, как альтернатива или дополнение к другим средствам туннелирования/энкапсуляции.
В остальном MPLS и NFV слишком далеки друг от друга и, условно говоря, относятся к разным уровням сетевого взаимодействия. Либо я неправильно понял что вы имели в виду. То, о чём вы пишете, косвенно напоминает тезисы об SDN. Термины SDN и MPLS, действительно, относятся к одному уровню и взаимозаменяемы, но реализуют диаметрально противоположные принципы сигнализации.
Эта статья не является маркетинговой, а вот следующая, видимо, вас расстроит — она, будет в официальном блоге Cisco. Но там, уж извините, будет, как вы и пишете, «тратата снижение капексов и опексов, тратата гибкость». Не иначе.
На данный момент цена исполнения транзакции, действительно, катастрофически высока — условно говоря 1 цент применительно к контракту, о котором я писал в статье при цене 1 Gwei per gas unit (да, еще 3 дня назад это было возможно). Последние 2 дня из-за возросшей нагрузки цена газа установилась выше на два порядка, так что при ограниченной пропускной способности сети в текущем релизе стоимость сильно вариаруется в зависимости от спроса. Но, для иллюстрации, если бы сетью мало кто пользовался, та же транзакция стоила бы порядка 1e-13 цента! И тогда одного доллара хватило бы для исполнения ежесекундных микротранзакций в течение 3000 лет.
Протокол Ethereum ждёт ряд изменений. И прогресс в любом из направлений роадмэпа драматически улучшает производительность сети, снимая остроту вопроса цены взаимодействия внутри стэка.
А вот что принципиально невозможно — это изобрести сразу быстрый автомобиль, не изобретая такое тяжёлое и медленное колесо.
— Можно ли предоставить виртуальный CPE (=Business CE) с поддержкой MPLS? — можно, притом даже в нынешних дизайнах Virtualized Multitenant Datacenter это не проблема. Например, на платформе amazon доступен Brocade Vyatta — это лишь один из линейки.
— Возможно ли использовать преимущества MPLS в таком режиме? — Скорее нет, т.к. MPLS сервисы требуют сквозной сигнализации меток. Для MPLS L3 VPN технологически возможны подобные схемы: Inter-AS-VPN, Carrier-supporting-Carrier, которые позволяют несколько вариантов пиринга с провайдером или через провайдера для сохранения сквозной сигнализации меток — но я не слышал о том, чтобы кто-то такой вариант применял в облаке — он всё-таки сложноват для оператора и плохо масштабируем. А для MPLS TE такого сквозного механизма нет вообще. К тому же, Service Chaining NFV предполагает простейшую топологию — линейную, а Multi-Tier Virtual Datacenter облака — тоже самую простейшую иерархию Tier-ов (или зон) — так что нет даже задачи, для решения которой можно было бы применять MPLS TE.
— Если для лабораторных задач, стэйджинга, то вполне возможно пириться виртуальными роутерами и в облачке внутри одного vDC (они должны быть l2-adjacent), также можно входить в этот домен средствами туннелирования снаружи. Возможна даже связь с реальной сетью или другой лабой средствами GRE tunneling, и пиринга по всем протоколам внутри таких туннелей.
Риски и затраты мне видятся не такими уж большими — точка входа для решения на несколько десятков Gbps (а в российских условиях это несколько десятков тысяч broadband-абонентов или сотни тысяч мобильных), лежит где-то в масштабах пары десятков серверов весьма средней конфигурации и пары недорогих 10GE-коммутаторов. Внедряться NFV также может постепенно — например, дополнительная услуга (скажем, родительский контроль и антивирус от какого-нибудь новго, альтернативного поставщика) может быть развёрнута поверх NFV, притом все остальные компоненты остаются legacy.
Что касается MPLS и NFV, то эти технологии пересекаются, как я вижу, в двух плоскостях:
1. MPLS традиционно используется на магистральной сети и сети агрегации с целью изоляции сервисов и упрощения форвардинга. Если NFV-сервис должен иметь продолжение в остальных доменах операторской сети — условно говоря, VRF/PW на границе сети, соответствующий MPLS FEC на сети ядра, PW на сети агрегации, VLAN на сети доступа — что угодно — то оркестратор, которому даётся команда построить сервис, должен внести соответствующие изменения во всех доменах: в ЦОДе (NFVI) и на legacy-сети. Если сервис требует изменений на MPLS-инфраструктуре, то это делает оркестратор, и для NFV-домена всё оказывается абстрактно. NFV ничего может не знать про MPLS и вланы на сети доступа, а сети доступа и агрегации могут ничего не знать про NFV.
2. MPLS может использоваться внутри NFV домена (внутри ЦОД, между хостами) как способ маркировки, как средство сегментации для service-chaining, как альтернатива или дополнение к другим средствам туннелирования/энкапсуляции.
В остальном MPLS и NFV слишком далеки друг от друга и, условно говоря, относятся к разным уровням сетевого взаимодействия. Либо я неправильно понял что вы имели в виду. То, о чём вы пишете, косвенно напоминает тезисы об SDN. Термины SDN и MPLS, действительно, относятся к одному уровню и взаимозаменяемы, но реализуют диаметрально противоположные принципы сигнализации.
Эта статья не является маркетинговой, а вот следующая, видимо, вас расстроит — она, будет в официальном блоге Cisco. Но там, уж извините, будет, как вы и пишете, «тратата снижение капексов и опексов, тратата гибкость». Не иначе.