Markus Nispel

Markus Nispel

Markus Nispel is the Vice President Solutions Architecture and Innovation at Extreme Networks. Working closely together with key customers his focus is the strategic solution development across all technologies provided by Extreme. In his previous role he was responsible as the Chief Technology Strategist and VP Solutions Architecture for the Enterasys Networks solutions portfolio and strategy, namely NAC Network Access Control, SDN Software Defined Networks, DCM Data Center Management, MDM Mobile Device Management Integration, OneFabric, OneFabric Connect and OneFabric Data Center as well as the network management strategy. This position is tied to his previous role in Enterasys as Director Technology Marketing and as a member of the Office of the CTO. In addition to this role he advises key accounts on a worldwide basis in strategic network decisions.
Before its activity for Enterasys Markus Nispel was active as system Engineer at Cabletron Systems.
Markus Nispel studied at the university of applied sciences in Dieburg and graduaded 1996 as Dipl. – Engineer for communications technology. He collected first professional experience at E-Plus Mobile Communications within the group of network optimization of their DCS cellular mobile network.

New Year Brings New SDN Challenges
January 23, 2014 Markus Nispel

New Year Brings New SDN Challenges

In 2014, we can expect more production deployments of SDN, and that’s going to force us to consider some key questions. Should the northbound interface be standardized, and how? And do we really know what we want out of network abstractions?

Application-Aware, Controlled, Centric, Software-Defined … Networking
November 9, 2013 Markus Nispel

Application-Aware, Centric, Software-Defined Networking

As Cisco’s Insieme launch showed, the network should be application-aware, and applications should be network-aware. The question is where to put the demarcation lines. Done right, it can produce agility, automation, and better delivery of applications

Application-Aware, Controlled, Centric, Software-Defined … Networking
November 9, 2013 Markus Nispel

アプリケーションアウェアな、制御された、アプリケーション中心の Software-Defined … Networking

Cisco の Insieme 販売開始が示していた様にようにネットワークはアプリケーションアウェアで、アプリケーションはネットワークアウェアであるべきだ。 問題はどこに境界線を置くかだ。 正しく行われれば、アジリティ、自動化とアプリケーションのより良い配信を産み出す事が出来る。

SDN Resource Management
September 23, 2013 Markus Nispel

Compute Isn’t Free: Resource Management in an SDN Network

Watch out for VM sprawl under SDN, because that’s what could happen if too many resources want the same things. There’s also a danger of watching compute requests spiral out of control, given that CPU cycles are now ‘free.’

SDN Programing
July 13, 2013 Markus Nispel

SDN: Who Does the Programming? And What Is The Level Of Abstraction We Need?

The industry has begun to converge on the main characteristics that make up a software defined networking (SDN) architecture, as you can see in blog posts like those on the SDNCentral “must read list” covering early 2013. In one of my previous blogs, I highlighted those characteristics, and there are various other articles out there, Read more >

Nispel SDN Software Defined Networking Guest Blog SDNCentral
July 13, 2013 Markus Nispel

SDN: 誰がプログラミングをするのか?どの程度の抽象化が必要か?

SDNCentral 2013年初頭の”必読リスト” の中のブログ投稿に見られる様に、業界は Software-Defined Networking (SDN) アーキテクチャを構成する主要な特徴に収束し始めた。 私は以前のブログの一つで、それらの特徴について強調したし、他にも Network Computing の様に様々な記事が出ており、アーキテクチャの仕様について議論の余地があるが、きちんとした説明が行われている。 私が SDN の特徴と終着点を考えた場合、次のようになる。: 集中化された管理と制御 ネットワークのプログラム能力 ベンダ間の相互運用性と統合能力 集中管理と制御は単一のポイントからネットワークインフラストラクチャに対してプログラム可能なアクセスを行う事を可能にする、分散アーキテクチャにおける中央コントローラもしくは他の中央コントロールプレーンコンポーネントによって実装する事ができる。 プログラミングと統合の為には明らかにオープンで使いやすい API が必要だ。(世界がともかく、XML に収束して行く。CLI や SNMP に比べれば、RESTFulになるか SOAP になるかは本当のところ重要ではない。; アプリケーションプログラマにとって数倍使い易い) 他にもおそらく必要なものがあるだろう。: ネットワークの抽象化だ。 抽象化のレベルは達成しようとするものによる。 もし、ネットワーク機器とネットワークトポロジーの全ての機能をネットワーキングおたく(つまり、ネットワーク管理者)に公開したいだけなら、全く抽象化を必要とはしないかも知れないが、どこに利点があるだろうか? そしてこれは OpenFlow コントローラのアプローチに目を通した時におそらく経験するものだ。: 正しい意思決定を行う為にはネットワーキングに関して多くの事を知っておく必要がある。 そしてネットワークに携わっていない人に必要だろうか? 一方、私にとって SDN は又、組織変更及び異なるプロセスについての話だ。 — ネットワークの管理に携わっていない企業内のビジネスラインの部門、つまり IT 部門以外に管理を委譲する事になる。 こうして真のアジリティが実現される。 それらのグループにおけるネットワーキングの知識は多分ゼロに近く、そしてそれを気にすべきではない。 — それでもちゃんと動作すべきだ。 だが、IT 部門の中で、システム管理者にネットワーク上でアプリケーションとワークロードを自動化されオーケストレートされた方式で導入させた場合でも — データセンタの典型的な SDN ユースケースだが、 — Read more >

SDN OpenFlow
June 29, 2013 Markus Nispel

Are We Now In The Post-OpenFlow SDN Wave?

Are We Now In The Post-OpenFlow SDN Wave? It feels like that even OpenFlow could play a role in SDN (as also OpenDaylight seems to support it) when either more custom ASICs (likely) or more scalable commodity ASICs show up (rather unlikely) and the control plane becomes much more scalable. I think the ONF did Read more >

SDNCentral SDN Blog Nispel 60282013
June 29, 2013 Markus Nispel

私達は OpenFlow 後の SDN の波の中にいるか?

私達は OpenFlow 後の SDN の波の中にいるか? カスタムの ASIC(ありそう)やスケーラブルなコモディティ ASIC(むしろなさそう)がより多く登場して、コントロールプレーンがよりスケーラブルになった時、OpenFlow は SDN において役割を果たすように思える。(OpenDaylight も又、OpenFlow を支援するように思える。) 私は SDN 関連の議論を始めるにあたって、ONF は良い仕事をしたと思うが、様々なブログで強調されているように焦点は Southbound API サイドのプロトコルに関する議論から、(標準化の欠如によって)様々なソリューションがある Northbound API を活用して SDN で本当のところ何ができるか、そして利点は何かという事に関連するより広範なアーキテクチャに関する議論へと移行している。 それゆえ、SDN ソリューションの本当に重要な要素と利点が今、焦点となっている。 – そして、先週の Interop での経験がそれを裏付けている。 水曜日のキーノートが OpenFlow に特に焦点をあてていたわけでなかったばかりか、Network World によって認定された今年のショーの最もホットな製品の一つが OpenFlow を使用していない SDN ソリューションだ。 – 更に、多くの SDN スタートアップが OpenFlow を使用しておらず、これに関する Isabelle Guis による先の SDNCentral のブログを見て欲しい。 私の見解では SDN アーキテクチャを構成する特性は次の通りだ。 管理とコントロールの集中 Read more >

SDN Controller
May 11, 2013 Markus Nispel

SDN と忘れられたデータプレーン — 私のフローと貴方のフローは同じか?

全てソフトウェアについての話だろう?全てが。 — Software Defined Networks という名前が示唆するように — ソフトウェアコンポーネント、API そしてアプリケーション統合機能にフォーカスしている。 しかしながら、私はその下でなにが起こっているかにもっと目を向けたい。: データプレーンだ。 コントロールとデータプレーンが分離されるべきか、又どのように分離されるべきか、それともハイブリッドなアプローチが取られるべきかというのはアーキテクチャ上の判断なので、– SDN の重要な概念である -“フロー”の意味が SDN インフラストラクチャにおけるデータプレーンを異なったものにしているという事を理解する事が不可欠だ。 一般的に、”フロー” はネットワークにおけるエンドポイント間の通信だ。 フローの定義はデータプレーンとコントロールプレーン両方において存在する。(必要がある。) 殆どのネットワークベンダはもはや大規模なフローベースのシステムを開発する為の専門知識を持っていない。 – スイッチとシステムのアーキテクチャ上の観点からも、必要な ASIC 開発の面でも。 そして更にコモディティ ASIC の市場はこれ迄、高価なメモリーをより必要とするスケーラビリティが要求されるので無視してきた。 そして高価なコストは必ずしも設計目標ではない。 従って、コモディティ ASIC 市場がこの分野を拾い上げる事を期待したとしても、今日、フローという面でスケーラブルなものを提供しようとする大手の ASIC プレイヤーはいない。 そして今日の殆ど全ての SDN スタートアップは参入に要するコストがハードウェアよりずっと安価なソフトウェア — コントローラ — によるソリューションにフォーカスしている。 一体、何故これが重要なのだろうか? フローベースのシステムを使用すると、最初のパケットはソフトウェア(従ってコントローラ、或いは他のアプリケーション)で非常に洗練された判断が行われ、そのフローの以降の全てのパケットはハードウェアでスイッチングされる。 これは又、SDN に伴う新しい、先進的、アジャイルなサービス全ての基礎となる。 ここまでコミュニティは集中化した SDN コントローラの設計とコモディティの ASIC では – コントロールプレーンとデータプレーンの両方においてスケーリングの課題に対処出来ないと説いてきた。彼らは2つの方法でこの問題を回避しようとしている。: フローの定義は粗くなっているので(集約)、コントロールプレーンにおける判断は少なくなり、データプレーンでプログラムされるフローの数も少なくなる。 そしてレイヤー 2 Read more >