誤解が生まれやすくなっている要因の2つ目は、OpenFlowが、これまでのネットワーク技術および運用方法に対するフラストレーションから開発されたという経緯にもある。大学構内のバックボーンネットワークを使い、新しいプロトコルを使った研究をやろうとしても、大学のネットワーク運用担当者がそれを許してくれない。こうした、ネットワーク利用者としての不満を解消することがOpenFlow開発の動機だったとされている。このため、自由で柔軟な環境を利用者に与えてくれない「ネットワーク屋」および既存ネットワーク技術からの解放というテーマが、OpenFlow関連の人々の活動や発言に見え隠れする。

　ONFのOpenFlowに関する標準化活動の体制も、これまでネットワーク関連で数々の標準を生みだしてきたInternet Engineering Task Force（IETF）の体制のアンチテーゼのようなところがある。IETFでは、基本的にはネットワーク製品ベンダーに属する人々（および研究者）が主体となって活動し、多数の標準策定作業を行ってきた。これに対してONFでは、クラウドサービス事業者や電気通信事業者といったユーザー組織のみで、理事会が構成されている。最近ではネットワーク製品ベンダーの人々が委員会議長などに就くケースが増えているが、あくまでも任命するのは上記の理事会だ。主導権をはっきりとさせた上で、必要に応じてネットワーク製品ベンダーのノウハウを活用するというやり方を採用している。

OpenFlowがここまで知られるようになった理由

　OpenFlowのアイデアとしての革新性に異論を唱える人は、あまり多くないだろう。だが、実装が困難であったなら、このプロトコルは現在のような支持を得られなかったかもしれない。OpenFlowでは、当初あらゆるネットワークスイッチ に共通の、基本機能であるパケット転送テーブルに着目した。これをOpenFlowプロトコルで外部から制御するインタフェースをスイッチに実装しさえすれば、OpenFlowに対応させられる（もちろん実際の実装作業は、これほど単純なものではない）。この容易さがOpenFlowというアイデアの革新性と相まって、ここまでの広がりを支えてきたのかもしれない。

　OpenFlowへの支持が広がったもう1つの背景は、クラウドサービスの発展だ。自動化を生かしてサービスの即時性とエラーフリーの運用を実現し、コスト効率を向上することが最優先課題である大規模クラウドサービスは、クラウド運用基盤と連動するネットワークの自動構成機能を必要とする。その実現技術の1つとしてOpenFlowに着目し、OpenFlowの周辺にエコシステムが出来上がることを望んできた。

　OpenFlowプロトコルでネットワーク機器を制御するOpenFlowコントローラーが、クラウド運用基盤とつながることで、「クラウド運用基盤と連動するネットワークの自動構成機能」、特にマルチテナントクラウドのテナント間分離が実現できる。これはOpenFlowの重要な利用シナリオの1つだ（ただし唯一の解ではない）。

　「ネットワーク屋」がこれまで、アプリケーション側のニーズを完全に無視してきたというのは大きな誤解だ。帯域管理では、古くはResource Reservation Protocol（RSVP）の例もあるし、トラフィックシェーパー（帯域制御装置）は広く使われている。また、「ネットワーク屋」がマルチベンダーのネットワーク環境を統合管理する仕組みを拒んできたというのも的外れな批判だ。日本のアラクサラネットワークスのエンジニアが標準化に大きく貢献したNETCONFのようなプロトコルもある。だが、大規模クラウドサービス事業者は、クラウド運用基盤と親和性が高く、データセンターにおけるネットワークサービスの自動化に都合のいいプロトコルとしてOpenFlowに着目した（繰り返すが、唯一の解というわけではない）。これが、OpenFlowの認知度向上を後押ししてきたと考えられる。

　そして、大規模クラウドサービス事業者の考え方や運用方法に興味を持ち、手本とする人々が多数存在する。こうした人々が、大規模クラウドサービス事業者の着目するOpenFlowに興味を持つ。OpenFlowは「オープン」「プログラマブル」「DevOps」といった、ソフトウェアエンジニアにとって魅力的な言葉に彩られることで、さらに多くの人々の注目するところとなり、その過程で誤解や拡大解釈も生まれてきたといえるのではないだろうか。

　第2回「【技術動向】OpenFlowに対する4つの誤解を検証する」では、OpenFlowをめぐる誤解についてさらに詳しく説明し、このプロトコルのより等身大の意義について探る。