“OpenFlow的学习与思考”有42个回复

1. igp2bgp 于 2011-07-25 3:44 下午

   难得首席没有调侃一番就发了小芳MM的文章，我得mark一下，学习学习

2. 三千大千世界 于 2011-07-25 4:24 下午

   看来最近在研究openflow的不少嘛 ：）

3. 陈怀临 于 2011-07-25 4:52 下午

   Heeeeeee.连美眉们都OpenFlow了：－）

4. zion 于 2011-07-25 5:20 下午

   Tex写的文？有个目录没有自动生成正确还是怎么的

5. zion 于 2011-07-25 5:28 下午

   如果仅仅是代码的解释，别人自然会自己去看代码

6. ber 于 2011-07-25 6:08 下午

   field? filed?
   有点影响阅读

7. futureenglish 于 2011-07-25 6:14 下午

   弯曲里美眉可不少啊，首席切记团结紧张严肃活泼。

   此文总结比较全面，没研究过的童鞋可以参考。

8. mylich 于 2011-07-25 8:30 下午

   to 5: 应该是docx的
   第六章相关项目有点简略…

9. 有意思 于 2011-07-25 9:06 下午

   村里有个姑娘叫小芳 ，(中关村)
   文档写的好又长。

10. 色狼二号 于 2011-07-25 9:34 下午

    whatever you do whatever you say yeah it’s all right..

11. outman 于 2011-07-25 10:00 下午

    在目前openflow只能说是步子太大忘了蛋，文章的刚开始就提到了重点，为了of的细粒度控制，openflow switch需要付出多少额外的表项存储能力，想象一下，在只需要现在switch 简单的mac表项查找的地方要连ip,tcpudp port,protocol之类的空间一起准备了，芯片的成本太高，原因仅仅是因为openflow的软件可以随便玩，而且多网域查找的复杂性远远超出switch简单的mac查找，即使是现有的tcam，也要很多条表项才能存一条of表项，so，等查找成本便宜的要命的时候再来玩openflow吧。。

12. outman 于 2011-07-25 10:02 下午

    为什么我的评论都要被审查。。我进入黑名单了么。。队长别开枪

13. insider 于 2011-07-25 10:43 下午

    作者可否联系一下eecs.cal (at) gmail.com?

14. multithreaded 于 2011-07-25 10:48 下午

    是不是让名字给骗了？

    有 Error 还照样怜香惜玉的给发了！

15. 叮当 于 2011-07-26 2:07 上午

    小芳mm不错啊。可曾婚嫁

16. 潜龙 于 2011-07-26 8:08 上午

    可怜夜半虚前席, 不问苍生问鬼神.

    叮当 于 2011-07-26 2:07 上午
    “小芳mm不错啊。可曾婚嫁”

17. AMDer 于 2011-07-26 8:11 上午

    首席魅力不小，大宋居里都给招来鸟。。。

18. 理客 于 2011-07-26 12:47 下午

    很好的总结，openflow之前也有很多的不错的文章，大体上很多人认为openflow的方向在open，不再flow，flow的路之前已经走过N次了，都没有成功，你可以看看flow之前走过的路，大体能得出一些flow不通的原因。

19. russellw 于 2011-07-26 1:03 下午

    和之前yeasy的文章文风很接近啊!

20. xaiolos 于 2011-07-26 8:06 下午

    mm好厉害，可惜我不懂。。。

21. aguai 于 2011-07-27 10:34 下午

    MM强大啊，值得探讨。

22. a 于 2011-07-29 2:21 上午

    自己管自己叫美眉？ 。。。。

23. adhoc 于 2011-08-01 5:31 上午

    学习了。

24. KISS 于 2011-08-02 7:42 上午

    理客对Openflow的论点有道理。希望学院派们能参考Linux的成功：充分利用现有的CPU，而不是从新定义CPU。

25. huhu 于 2011-08-12 8:21 上午

    呵呵，以前想翻译一下的

26. huhu 于 2011-08-12 6:07 下午

    希望能够和原作者联系，很多想法我们都是一致的。

27. huhu 于 2011-08-12 6:17 下午

    感觉这吧不像是mm写的啊，你或许是在ucb访问过的一个同学？

28. Russellw 于 2011-08-15 5:23 上午

    关于OpenFlow，可以参见BigSwitch和Nicira这样专门为OpenFlow而生的Startup公司的思路和产品。个人认为OpenFlow能否成功的关键是有没有可能研制出一款能够NATIVE地执行FlowTable中的报文处理宏指令的Processor，并且在性能、成本上可以接近现有ASIC/NP的解决方案，如果可以，那么软件定义网络的理念就可以成为现实。
    现有很多的评论是基于现有的硬件来实现OpenFlow转发面而得出的结论，有道理，但不是全部。我认为对客户的价值是评判技术的最终标准，而技术可行性本身的障碍决定技术导入的时机，只要不是绝对不可行的，终会被市场所克服。我本人看好软件定义网络的价值，但短期内的硬件技术是否已经满足其要求，我还不敢下结论。

29. 小芳 于 2011-08-15 2:25 下午

    huhu你给sdn.thu (at) gmail.com发信吧
    Russellw方便的话也交流交流吧!

30. 小芳粉丝001 于 2011-08-15 8:12 下午

    小芳mm现在哪里工作哇？
    有几个技术问题也想请教一下。

31. 根本不相干 于 2011-08-15 11:01 下午

    由于和我的研究领域相关，所以也一直在关注openflow的进展。

    关于表项数量问题，OF1.1多表pipeline的出现一定程度缓解了1.0的矛盾，当然这以增加转发逻辑复杂性为代价

    我感兴趣的是：Openflow能否对所有天然需要fastpath-slowpath架构的网络业务设备开发，起到简化的作用？理想情况下，业务功能的扩充与调整，主要反映在slowpath的开发，而fastpath相对稳定

32. ucb 于 2011-08-15 11:08 下午

    1. Nicira现在的发展已经远超出大家的想象
    2. OF原有的硬件限制也已经解决
    3. 国内现在清华跟的比较紧, 还有几个公司

    欢迎大家一起讨论, 我的gmail: sdn.ucb

33. 根本不相干 于 2011-08-16 5:32 下午

    看来很多人有深入讨论需要，不知哪里建一个mailinglist或group方便？

34. mota 于 2011-08-16 6:14 下午

    32 ucb, 你说的硬件限制解决了不妨拿出来简单晒晒

35. 小芳 于 2011-08-16 8:50 下午

    大家好，建了一个讨论组和maillist。
    http://groups.google.com/group/sdn-discuss

    欢迎对sdn技术感兴趣的弯曲的朋友加入，大家一起讨论！

    ps，首席莫要怪我做广告哦~

36. interbeing 于 2011-08-17 12:03 上午

    open flow slow path 都要在controller建

    假如几千个服务器上的虚机中了病毒。按地址段乱发数据包，这样控制面在同时可能要建立很多的新的flow.
    即使这些flow是简单的3层。那么controller每秒也要创建大量的flow. 这个controller的扩展性能不能支持到？

37. russellw 于 2011-08-17 5:38 上午

    to根本不相干:
    你的关注点和我在某种程度上类似，从小处着眼，我理解OpenFlow的架构是SoA在网络设备领域的体现，将Fast-Path转发行为原子Service抽象出来，Flow(此Flow非彼Flow)在Slow Path实现，原子操作是稳定的，业务流程是多变的。对初始设备版本而言，开发可能反而复杂了，但是对产品整个生命周期理论上是减少了工作量，如果能够形成整个网络产品族的平台，则价值方能真正体现出来。
    其实大家做网络产品，内部的转发面、控制面基本上都是这么设计的，差别在于对primitives的归纳、抽象能力。

38. 理客 于 2011-08-17 2:08 下午

    OPENFLOW硬件是个类似鸡蛋的问题，以太和POS的硬件复杂度差多少呢？但以太已经便宜的不行。许多新技术都要解决鸡蛋问题，包括Google的android，依靠自己的技术实力和业界领导力，快速的解决了鸡蛋问题，逼得apple和MS不得不大打专利牌。对于OPENFLOW，一定要向着正确解决鸡蛋问题的方向努力，才有希望成为将来的王道，成为传统转发的终结者，这个机会肯定是有的，但要看openflow能否在合适的时间，抓住这个机会，快速长大，在摩尔定律下的IT，不能在规定的时间长大，比如5年，基本就要被退出历史舞台，这样的技术太多了，比如wimax、PBB等等，做技术方向把握和决策的，不可不察。

39. 根本不相干 于 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共存于本地，但可与中央数据库同步策略。

40. 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集合，如果强求统一的解决方案，失败可能性倒是很高

41. 根本不相干 于 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的后路(呵呵也只能在首席这个开放平台说说)

42. test 于 2012-01-04 3:45 下午

    请教教主，硬件实现的限制如何解决？