当初は自動化やビジネス・オーケストレーションといった輸入コンセプトがネットワーク・エンジニアにどのように役立つかを説明するために使用され、その後OpenFlowのようなプロトコルがネットワーク・プランニングとアーキテクチャのためのより大きな青写真にどのようにつながるかを説明するために使用されました。
今、SDN はベンダーが売ろうとするどんな製品にも付けられる乱用されるバズワードに変わり、ベンダーもまた SDN を使って彼らが売りたい機能を宣伝するのが好きです。昨年、Ivan Pepelnjak はダイアルアップユーザが設定を自動化するための Perl の使用について書き、それを 1993 年の SDN と表現しました。
おそらく、過去の SDN に終止符を打ち、新しい意味と名前を与える時が来たのでしょう。 SDN 2.0 は顧客に売ろうとする曖昧な概念ではなく、YANG や NETCONF スクリプトでもなく、基本的なインタフェースを持つ単一のオペレーティングシステムでもないでしょう。SDN 2.0 のラベルを製品の箱に貼るには、ベンダーは3つの要件を満たさなければなりません：
1. 自動化SDN 2.0 を実装するためにはネットワークにインテリジェンスを組み込む必要があります。スクリプトや API ではなく、ネットワークのために "考える" ある種のコントローラやオーケストレーションデバイスが必要です。ネットワークデバイスは何らかの方法でこのコントローラと統合される必要があり、もし管理プラットフォームがデバイスと "会話" できなければ SDN 2.0 にはなりません。
2.プログラマブル.コマンドラインでの制御はもうやめましょう。コマンドを自動化できないのであれば、REST APIを使ってインターフェースを生成するか、いっそのこと管理コンソールからしかインターフェースを表示できないようにしましょう。もし人々がCLIに固執するのであれば、プログラマビリティは保証されなければなりません。
3.オープン.もしソリューションがクローズドソースであるなら、それは SDN 2.0 ではありません。SDN 2.0 はオープンで全世界に公開されるべきです。なぜなら、ごく少数のベンダーのプログラマだけがシステムが実際にどのように動作するかを知っていて、奇妙な問題を解決できないのは容認できないからです。
SDN の用語を捨てて他の新しい用語を使うことは、顧客の問題を全て解決するわけではありません。ベンダは、たとえそれが全く正しくなくても、彼らのソフトウェアの定義が正しいと説得しようとするでしょう。ベンダーが SDN 2.0 仕様に準拠した製品のすべての機能をリストアップすることで、顧客は製品をよりよく比較することができます。
