什麼是開放網路？

網路行業的發展如果非要歸納出一個明確的發展趨勢的話，那這個趨勢無疑是「開放」。業界有一個奇怪的現象，但凡涉及到「開源、開放」的技術或者社區，好像都比較受到追捧，網路行業也不外如是，那麼到底什麼是開放網路呢？

網路用戶和運營商長期以來一直在傳播這樣一個觀點，他們認為開放是指支持組織的自由替代。如果我現在在網路中有個A盒子，它可以用B盒子加以取代，那這就是開放網路。但是這是不是就意味著用戶可以簡單地在同一個位置取代設備？這些介面是否完全相同？用戶能夠接受需要微調以支持硬體取代的網路嗎？甚至是只支持主流硬體替代的「開放」網路嗎？

撲朔迷離的未來

傳統網路設備有三種類型的介面。一類支持埠/中繼數據平面連接。另一種支持的控制交互，第三種支持設備管理。軟體組件在某種意義上等同於身，需要獨立的介面，通常被稱為應用程序介面即API，我們將網路軟體API歸類於設備介面相同的第三個種類中。事實上，像託管路由實例一樣的網路軟體將具備這三類介面，但是它們同時還具有一整套設備從未顯示的API，而這些API使軟體定義中的開放性變得撲朔迷離。

假設用戶需要託管一個Virtual_Router單個軟體元素，用戶必須能夠將其部署在需要軟體和一組API的伺服器上，用戶必須能夠管理伺服器和路由器實例。

當用戶希望能夠擴展虛擬路由器的埠和中繼介面時，這種情況將變得不受控制。埠和中繼件必須連接核心路由器元素——另一套API，用戶可以在完整的軟體定義網路（SDN）或網路功能虛擬化（NFV）中輕鬆識別幾十個API，並且部署完成的SDN/NFV可能具有數萬個API。處理數量呈爆炸式增長的API，廠商給出的方式是將API發布在某種目錄中。

然而，這種方式效果非常有限，因為API不是我們在設備中可以看到的物理介面，設備通過物理介面以非常具體的方式互通。API不會描述集體圖案管虛擬設備的工作原理，而是如何在虛擬設備內部進行工作。API支持軟體組件工作流程，但是當路由器具備標準功能時，每個路由器供應商將其軟體分成相同的組件？還是使用完全相同的信息格式來進行通信？

舉個規模化網路軟體的負載能力的例子，一個廠商可能會在其「規模化控制」API中要求每個分組數據包的規模限制，另一廠商可能希望根據託管它的處理器的CPU利用率來規模化組件的副本。第三個廠商可能都不接受明確的規模化控制。當今開放的最大問題是，開放API不僅僅意味著已發布的API，還意味著通過API的信息格式，並且取決於軟體實現的細節。

基於意圖（intent）

網路軟體正在試圖通過一種基於所謂「意圖」的層次建模來解決這個問題，意圖模式描述「what」所指的是功能而不是實現方式（How）。由於暴露了特定的屬性顯式API，虛擬路由首先被建模，任何想要成為虛擬路由的東西都必須具備這樣的高級模型。其中可能會定義「port-instances」和「trunk-instances」，它們描述了虛擬路由的各項功能，但在某種程度上，某一部分的意圖模型包含隱藏或專用的邏輯，這些是不開放的。

用戶可以根據開放的定義將一個兼容的虛擬路由替換成另一個虛擬路由，如果虛擬路由模型分解成「port-instances」和「trunk-instances」模型，那麼也可以通過替換這些加以實現。然而，如果基本的核心路由邏輯不是單獨建模的，那麼用戶不能實現設備或虛擬路由的替換。

這意味著在我網路軟體和軟體驅動的網路中，我們承認了一切都不開放且不允許實現專有的變化的方式來表述所謂的開放性的概念擴展。這意味著開放API本身就是一個笑話，因為它不具備任何意義，開放的未來是將功能與實現分開的軟體建模的未來。

我們應該關注的是如何建立軟體建模，如果我們可以為設備和設備網路定義標準結構，並且可以在基於意圖的層次結構上構建這種標準的網路，我們未來的軟體定義網路元素將遍地開花，這也是我們所期待的。