IBN:傻瓜式网络配置

(a.k.a. Intent-Driven Networking, Intent-Based Orchestration/Management, [Intuitive Network, Self-Driving Network])

意图驱动网络这个概念其实从2015年就陆续有人开始有这个想法，但是各个机构之间信息不互通，或者说想法不完全一致，所以一路走来有了很多名字，可是直到今天依旧没多少人熟悉IBN的概念，我们今天就来聊聊这个比较超前的话题。

什么是IBN

“In the so-called “Intent” model, intelligent software (such as an SDN Controller) determines how to translate the Intent into an infrastructure-specific “prescription” that causes the network to behave in the desired manner.”

​ from Intent: Don’t Tell Me What to Do! (Tell Me What You Want)

在所谓的‘意图’模式中，智能软件(如SDN控制器)将决定如何把意图转化为针对特定基础设施的配置手段，从而使网络以人们期望的方式行事。

“总体来说，IBN是一种在掌握自身“全息状态”的条件下，基于人类业务意图去进行搭建和操作的闭环的网络架构。”

太抽象了，我们来举个栗子：

某网络负责人希望web集群内新上架的一台服务器对外提供HTTPS协议服务(意图)。系统感知到这台服务器的IP为x.x.x.x ，且自动将这个意图转译为“配置ACL(access control list)仅允许外界对IP x.x.x.x的访问通过端口443进行”(执行)。

传统网络的方法 versus IBN的方法

我们把用户需求和网络实体状态之间的关系划分成三部分：意图->指令集->结果

在传统网络下，用户/管理员需要做的事情是“确定意图” 和“转换成指令集”，再由网络实体来执行这些指令，最终达到网络状态的改变。

在IBN网络下，用户只需要表述目的，至于“翻译成指令集“和“执行过程”都由网络自动完成，相当于管理员对用户“透明化”了，最终的理想结果就是：即使这个用户什么网络知识都不懂，凭着一句“我想要这台电脑网速快一点”，IBN也能实现相应的优化。

How IBN Works

IBN系统主要由以下五个步骤构成完整的闭环：

1. 意图的收集(Intent Collection)： 即收集意图发起者期望达成的网络情形，在意图尚未生效前可以进行灵活修改。
2. 转译和验证(Translation and Validation)： 将意图转化为网络能理解的语言——策略(policy)，并根据网络的状态实时验证该策略的有效性，如果验证不通过将会返回第一步。
3. 自动下发与执行策略(Automated Implementation)： 转译出的策略在通过验证后由IBNS自动下发到网络基础设施上，并自动执行。
4. 自发的优化补救(Self-remediation)： 网络的状态时时变化，执行时的状态与验证时的状态可能存在不一致，此时IBNS会主动地根据期望的状态对策略进行优化补救 ，这一过程中不需要人类介入。
5. 实时反馈 (Post-Assessment)： 将结果返回至意图的发起者处，这个结果可以是意图已经达成，或者是意图需要被重新定义。反馈仅在需要人类介入时才触发。

IBN Requirements

网络要有全面、精细、实时状态

网络的状态就是指网络中各个网元上的状态信息以及它们之间的流量状态信息。对网络状态的验证是解释用户业务意图合理性的决定性指标也是将其转化成实际策略并验证生效的唯一途径。获取网络状态，可以解决网络配置不能大规模并发的现状，极大地提高了效率。同时，为了更好地验证意图并产生对应的策略，获取的网络状态需要是全面的、精细的、实时的。

对意图的转译和验证

意图是IBN体系中的核心驱动力，IBN将对于意图的理解穿插到网络的生命周期中，由基于算法的意图模型去分解、转译意图；在意图被下发至网络基础设施之前，必须确认其可行性。这项操作基于对网络全息状态的掌握，在下发前后持续进行验证，目的是为了保证原始的业务意图能被不折不扣地达成。

网络的自动化

IBNS进一步实现了网络生命周期管理中的设计、配置、变更和运维等过程的自动化，同时实现了闭环，让网络成为一个可自动控制，自动运转的系统。

形成持续的闭环

从一条意图被录入IBNS开始，系统的各个流程就需要维持一个闭合的环路。唯有持续闭环的系统才可以保证意图的有效性，才可以确保意图不会被突发的网络状况干扰，半途而废。

IBN versus SDN

SDN(Software-defined Networking)即软件定义网络，业内对于SDN的界定非常的清晰：

1. 将网络的控制平面与转发平面分离，并存在独立的控制器
2. 控制器与交换机之间采用开放的南向控制协议(比如OpenFlow)
3. 控制器提供开放的北向API，能够以可编程的方式实现控制

SDN是一种网络构建的方法，而IBN在实现层面更多的是以整体IBNS的系统形式存在。SDN和IBN是两种互帮互利的技术，它们既可以各自独立部署，也可以混合部署于网络中，前面提到的ONF所提倡的NBI项目目的之一就是为了更好的支持IBN技术 。

此外，SDN更专注于如何控制网络中的基础设施，基于软件，以开放、可编程的方式进行网络策略的配置。IBN的控制环节，可以是传统控制，也可以是SDN控制。IBN更关注如何使得网络能够更好地满足用户的业务意图，使意图和网络状态之间可以平滑地、持续地达成高度一致。

如果我们思考SDN的南向接口（与应用层交互的接口），可以发现其实上层应用和SDN controller的交流也是基于“意图的，只是这时候应用的意图都已经被人为精准而细致地定义好了，如果我们把南向接口扩充，抽象成可以接受“人”和“应用”的意图接口，这个时候SDN和IBN就在互相混合、靠拢了。

Benefits of IBN

从长远利益的角度，IBN基于业务意图，对于网络全息状态的获取和对设备细粒度的控制都毫无疑问给网络带来了巨大的敏捷性；同时它无需依赖于物理网络层的各种设备和厂商纷繁不同的接口，继SDN以后更进一步地解除了厂商的绑定。从运维层面，这也解决了异构环境之间网络的管理问题，使得用户能够完成以意图为导向，以策略为介质的高集中度统一管控。

从眼前利益出发，IBN融入了网络自动化(Network Automation)，降低了网络的复杂性，大幅提高了运维效率，也很大程度上节省了人工，为企业带来Opex效益。2017年Gartner曾在报告中指出：“我们认为一套IBNS的部署可以减少50%-90%的网络基础设施交付时间，同时可以减少至少50%的宕机发生次数和时长”。在增加了网络的鲁棒性、提高了网络安全性的同时，对于网络全局性的把握可以针对业务应用进行单独的优化和配置，增强了应用的性能，紧密了应用与网络之间的关联，为企业的数字化业务转型做了铺垫。

Chanlleges of IBN

从用户角度分析，IBN正式的商业化技术应用是从2016年开始，因此面临的第一个挑战就是时至今日仅有极少数人真正熟悉这个概念。其次，在IT这个普遍存在脆弱性 、技术周期相对较长的行业内进行新技术的尝试将会面临极大阻力：高层管理者对于风险的敏感，采购尚不存在针对IBN的独立预算，市场尚无广泛反响和经验可借鉴等等，都会制约IBN技术的进一步发展。

从生态角度分析，在IBNS的运行过程中，各个组件和设备大量地依赖相互之间的API/CLI对接，目前统一的标准规范尚未形成。然而这是一个存在利润冲突的区域，目前厂商各自存在私有的API/CLI，以此建立的壁垒隔绝对其他IBN组件的支持，这会从很大程度上抑制异构组件的IBN闭环的成型。