- Russellw 于 2011-08-15 5:23 上午
关于OpenFlow，可以参见BigSwitch和Nicira这样专门为OpenFlow而生的Startup公司的思路和产品。个人认为OpenFlow能否成功的关键是有没有可能研制出一款能够NATIVE地执行FlowTable中的报文处理宏指令的Processor，并且在性能、成本上可以接近现有ASIC/NP的解决方案，如果可以，那么软件定义网络的理念就可以成为现实。
现有很多的评论是基于现有的硬件来实现OpenFlow转发面而得出的结论，有道理，但不是全部。我认为对客户的价值是评判技术的最终标准，而技术可行性本身的障碍决定技术导入的时机，只要不是绝对不可行的，终会被市场所克服。我本人看好软件定义网络的价值，但短期内的硬件技术是否已经满足其要求，我还不敢下结论。
- 理客 于 2011-08-17 2:08 下午
OPENFLOW硬件是个类似鸡蛋的问题，以太和POS的硬件复杂度差多少呢？但以太已经便宜的不行。许多新技术都要解决鸡蛋问题，包括Google的android，依靠自己的技术实力和业界领导力，快速的解决了鸡蛋问题，逼得apple和MS不得不大打专利牌。对于OPENFLOW，一定要向着正确解决鸡蛋问题的方向努力，才有希望成为将来的王道，成为传统转发的终结者，这个机会肯定是有的，但要看openflow能否在合适的时间，抓住这个机会，快速长大，在摩尔定律下的IT，不能在规定的时间长大，比如5年，基本就要被退出历史舞台，这样的技术太多了，比如wimax、PBB等等，做技术方向把握和决策的，不可不察。
- 根本不相干 于 2011-08-18 12:22 上午
to russellw
没错，我的确是这个意思：“其实大家做网络产品，内部的转发面、控制面基本上都是这么设计的，差别在于对primitives的归纳、抽象能力。”这个归纳抽象非常重要，是最体现对网络业务深刻理解之所在；而OF目的之一就是定义一个各厂家都能通用的primitives集合，帮助后来者降低进入网络设备开发的门槛，有些类似windows界面刚出现时，MFC所起的巨大作用。
可是我认为OF另外两个目的必定失败：1)独立于设备的外部集中控制面；2）primitives硬件实现。
第1点我不多说了，已有很多对OF该特性诟病的论述。拿经典的Nicira为主实现的OVS实现来说，它也提供了集中策略配置预下发到各节点，slowpath controller由各节点分别本地处理的折中方式，无疑该方式把大量跨节点协议流量变为本地PCIE流量，相当实用。这种折中实现，我更看好
第2点涉及OF的定位：简单的L2/L3转发不需要复杂的controller；复杂的业务难以固化primitives，比如说1.1对1.0就是巨大的改动，现在又在探讨1.2(需求搜集稿中不少特性需要硬件更改)，那么要想保护硬件投资只能提高其可编程能力，可这样又违反了OF的初衷。
所以，我比较看好的是OF用于CPU实现network appliance的场景，fastpath方式能大大提升软件的性能(在策略规则较多时，传统Linux Bridge几近瘫痪，而OVS则能基本保持平滑)，对应的controller则与fastpath共存于本地，但可与中央数据库同步策略。
- russellw 于 2011-08-18 8:04 上午
to:根本不相干
你讲的两点，我也认为是问题，但没有那么悲观。集中控制对于运营管理可以降低管理成本，而且控制信令流量和管理的颗粒度是有关系的，比如数据中心中大部分流量按MAC转发，ACL预下发，然后让虚拟机调度器和Controller联动起来实现VM动态策略下发，控制面流量是可控的。当然如果管理到每个流，那么根据CAIDA的抽样数据，1个10G路由器每秒新建流11K,管理n个路由器就需要n*11K/s*2的控制面流量，稍有些高。
关于用硬件实现Primitives，可以参考X86的指令集，简单看mov/cmp/jxx/add/sub/mul/div/inc/dec这些指令，谁又能想到其支撑了近四十年的PC软件发展呢？当然X86不是万能的，还有DSP、GPU做其它事，OpenFlow也是如此，不可一套指令集包打天下，Datacenter、接入网、骨干网的需求差异较大，可能需要不同的primitives集合，如果强求统一的解决方案，失败可能性倒是很高 - 根本不相干 于 2011-08-18 5:46 下午
我认同集中控制的价值，也认为流的粒度是关键。设想一下：假如controller分布在每个switch节点上，那么大部分控制面交互可通过本地PCIE完成，然后controller可以和中央数据库同步(同步方式可以是主动预push和按需pull的结合)，而这种同步的粒度相对较粗，而且协议也可以简化（比如Nicira就自定义了一套）。
当然，OF组织的初衷是立足于网络管理员层面，希望把整个系统设备当成黑盒，无需关心内部软件控制面实现，只要它出标准OF协议，就可以操控它了。立意虽好，但即使抛开技术，商业上抵触也会很大，目前业界重量级vendor基本都是表面喊支持，背后轻微动一下出个规格不完善的版本意思意思。
而我认为只要把fastpath dataplane与slowpath之间的交互定义清楚就好了，集中控制如何实现可以交给设备开发商自己。这样芯片厂商可以开发switch硬件，开源组织也可以独立维护稳定的底层fastpath代码。至于系统设备，C/J/W不做，自有大量第三方starup和google自行定制等形态出现，无需受制于传统vendor的制约。
小结一下：革命希望不能放在既得利益者身上。OF组织把希望寄托于系统设备层面不现实，应转向fastpath组件层面，降低大量第三方设备开发商以及最终用户自行开发的门槛，抄了传统vendor的后路(呵呵也只能在首席这个开放平台说说)
openflow可以死，但SDN一定活。最终的生存之道，一定是比现有的产品方案能大幅降低TCO，否则无论它有多先进，初始有多风光，都不得不死，比如铱星，比如ATM，这是人类进步的一个基本价值规律。
就SDN来说，它具有长期大幅度降低网络成本的本质，所以一定活。
open之所以能降低成本的核心在于量，所以用专用的芯片比如ASIC，甚至不易编程的pipeline都未必是正确的选择，有效降低成本需要的是通用转发芯片，硬件转发芯片将是NP和多核的PK，在高性能网络，核心转发代码一定是少的，否则就很难高性能，目前路由器越来越复杂，但实际上针对某个具体固定的场景，使用的代码可能只是总体代码的1/3，所以SDN可以按需定制。
只要量上来，即使复杂如X86的芯片，也会按照摩尔定律把成本降下来，SDN的硬件是核心转发NP/多核+可选的TM可编程芯片+可选的交换芯片，至于要SDN的生态系统核心掌握在谁手里，现在说鹿死谁手还为时尚早。
open的本质在于海量，如果不能达到海量的目的，就一定会死，达到海量的手段是SDN
- russellw 于 2012-05-02 6:19 上午
以前在国企时，大家开玩笑说不少项目都是三拍工程：决策时拍脑袋、执行时拍胸脯向领导保证、验收时拍大腿。如果拍脑袋就能行，政府、大公司就没有必要养那么多智囊团和研究机构了，理论上，100%完全的信息就可以得到正确的决策，但是现实世界中信息都是不完整的，决策就是风险管理，参谋负责提供尽可能多的信息，领导者拍板决定，并且决定风险规避方式。
零风险决策傻子会做，纯拍脑袋的老板多半是疯子。
在市场经济条件下能够掌管一个公司的多半既不是傻子也不是疯子，但是方向正确、做正确的事固然重要，正确地做事、把事情做到足够好也是竞争的必要条件，否则就是志大才疏之流。
上面各位谈山石选择Openflow，我是SDN的big fans，当然支持，但是对一个企业来说关键是你从中能够找到什么样的市场机会，能够基于SDN提供什么样的可以吸引客户的解决方案。或许安全公司能够从SDN中挖掘OF switch做Fast path来降低整体解决方案成本的可能性，或许可以形成和OF Controller联动构造整网安全解决方案，但是你要做到足够好
russellw 于 2012-05-16 8:34 上午
-
to zuoy:可以微博私下联系。
关于SDN和Forces的对比问题，其实和大家提到了的NGN、智能网和SDN对比的问题类似。再往前看，X.25、ISDN、ATM是不是都是分组网络，IPX/SPX、NetBIOS、NetBEUI是不是都是网络协议，为什么拼不过IP？我的观点是技术不能回答这个问题，关键在于技术体制所构成的生态链，上下游厂商是否能参与进来，是否有好处？成本如何？IP除了其足够简单、可扩展性相对较好外，产业链相对开放，并得益于早期Unix操作系统的广泛支持。SDN画了一个大饼，芯片、设备供应商(Cisco除外)、安全厂商、IT厂商、运营商均看到或多或少的利益，并且ONF采用会员间专利自动交叉免费授权的IPR策略从某种程度上可以避免参与者的IPR风险。
换句话说，你自己一个人玩，把别人都当作假想敌，注定无人喝彩，做成一件大事，必须要有一个ecosystem。CDMA为什么被抛弃，也一定程度上说明了这个问题。
近期我也写了一篇文章，分析了一下SDN对产业链的影响，发布在微博上，请大家指正OpenFlow 的學習與思考
控制
NOX 对流量的控制是通过管理交换机来实现的。网络功能诸如DPI 通过重定向网络流
量到中间件来实现。
扫一扫
3392
到【灌水乐园】发言
to根本不相干:
你的关注点和我在某种程度上类似，从小处着眼，我理解OpenFlow的架构是SoA在网络设备领域的体现，将Fast-Path转发行为原子Service抽象出来，Flow(此Flow非彼Flow)在Slow Path实现，原子操作是稳定的，业务流程是多变的。对初始设备版本而言，开发可能反而复杂了，但是对产品整个生命周期理论上是减少了工作量，如果能够形成整个网络产品族的平台，则价值方能真正体现出来。
其实大家做网络产品，内部的转发面、控制面基本上都是这么设计的，差别在于对primitives的归纳、抽象能力。