“软件定义网络”术语最终走到了尽头，最初它被用来解释自动化和业务编排等导入概念如何可以帮助网络工程师，随后这一术语被用来描述OpenFlow等协议如何引领我们到网络规划和架构的更大蓝图。
现在，SDN已经变成一个滥用的流行语，被附加到供应商试图出售的任何产品上，供应商也很喜欢利用SDN来吹捧他们想要卖给你的功能，也许这是他们设备中的一个应用编程接口(API)，或者是操作系统中自动执行命令的一系列脚本或宏，去年Ivan Pepelnjak还写道使用Perl来为拨号用户自动化配置，并将其描述为1993年的SDN。
也许是时候给过去的SDN画上一个句号，并重新赋予意义和新名称，我们暂且将其称之为“SDN2.0”，SDN 2.0将不会是试图出售给客户的模糊的概念，它不会是YANG或者NETCONF脚本，也不会是具有基本界面的单一操作系统，供应商想要在其产品包装盒上获得SDN 2.0标签，必须满足以下三个要求：
1. 自动化. 为了实现SDN 2.0，你需要构建智能到网络中，而不是脚本，不是API，你必须有某种控制器或编排设备为网络“思考”。你的网络设备需要以某种方式与这个控制器集成，如果该管理平台不能与你的设备“对话”，你就不属于SDN 2.0。
2. 可编程的. 不再有命令行控制(CLI)，如果你不能自动执行命令，使用REST API生成一个界面，更好的是，只允许从管理控制台查看界面。如果人们一味地坚持自己的CLI，那么，必须保证可编程性。
3.开放. 如果你的解决方案是闭源，那么就不是SDN 2.0，SDN 2.0应该是开放的，对全世界可见的，因为只有极少数供应商程序员知道系统实际如何运作，而导致无法解决奇怪的问题，这是不可接受的。
放弃SDN术语而转向其他新术语并不能解决客户的所有问题，供应商仍然会试图说服我们，让我们相信他们的软件定义是正确的，即使根本不是这么回事，但使用一个有着严格规范的新术语是有用的。通过让供应商列举出其产品符合SDN 2.0规范的所有功能，这让客户可以更好地对比产品，这也能够防止供应商向客户出售没有达到标准的产品，并突出那些符合标准的产品。
