NCN 意指 next cloud network，现在的 VPC 终极目标为虚拟网模拟传统网络提供给用户，但其实虚拟网和物理网面临着完全不同的技术问题，即以兼容和对传统网络协议畏缩的名义人为的造成用户业务形态和网络形态的割裂问题，解决方式是客户提高对传统网络的认知并适应虚拟网的逻辑，但此举无疑给甲乙双方都带来了不小的麻烦。NCN 意在屏蔽传统网络，向用户提供面向应用的 IaaS 产品形态。

NCN 也意指 native cloud network，不仅提供云原生的解决方案，更是直接提供面向应用和业务的原生云。

设计理念

SDN 模型的选择

按照 Google Andromeda 对 SDN 网络的编程模型定义，可以划分为如下三种：

Preprogrammed Model

On Demand Model

Gateway Model

其中，三种模型都有各自的特点：

模型	特点	优点	缺点
Pre programmed Model	预先下发 full-mesh 规则	一致性、性能可预测性	控制面复杂度是网络规模的 O(n2)，任何网络变化都需要传递至所有节点
On Demand Model	网络流的第一个包被送至控制面下发规则。	比第一种拥有更好的扩展性	1. 首包拥有非常高的时延； 2. 对控制面负载状态很敏感，且一旦控制面出现故障，新的网络连接将不再能建立； 3. 控制面会受到 DDoS 攻击
Gateway Model	VM 把所有流量都送到中心化网关处理	性能可预测性、扩展性	网络流量的均值和峰值差距非常大（可能超过 100 倍），导致网关模式的利用率很低、TCO很高

基于此，Google 公开了其仙女座虚拟网络控制平面使用的模型: Hoverboard Model

但个人认为 Hoverboard 还有一些不足的地方，转发模型一节会详述：

由控制面根据网络情况决定卸载流量过于理想化，应由数据面转发规则容量动态卸载；
缺少网络的自愈性

转发模型的选择

VPLS + IRB

我们知道在云网络中，热迁是基本的需求，当寻址信息发生变化时，如何尽快的收敛网络？L2 的 FIB 不依赖 RIB，这是一个很好的选择，所以 VPLS 模型成为了首选。

但同时 VPLS 存在一个严重的问题，需要数据层进行 flood-learn，这极大的限制了网络的规模，所以有了如 OpenStack L2Population 和 EVPN 这样的控制面。

此时，L3 仍然可以通过 IP 地址聚合来提升控制面的规模和性能，但随着东西向跨子网流量的增加和网关利用率的问题，IRB 成为了必要的选择：

OpenStack DVR：PBR + Namespace，其实更好的选择是 VRF
OVN：本地具有全部的 Pipline，对端完成逻辑结果到物理的映射
BGP EVPN：Asymmetric IRB or Symmetric IRB，简单点说就是 MPLS 在 L2 和 L3 VPN 方面的应用，并依靠 MP-BGP 分发控制面信息，数据面使用 VXLAN 替代
Tungsten Fabric：本质上就是 MP-BGP，集中式的控制器相当于一个 RR

这就有了一个好笑的现象，从一开始选择不依赖 RIB，到现在维护两套 RIB，这是不可取的。所以以此模型为基础的金山云、百度云等，乃至传统网络侵入云业务的分布式控制并不切合大规模公有云。

NBMA

虚拟网中，R&S 是否还有保留的必要？交换的本质是隔离冲突域，提高以太网这种广播型链路的交换效率，Mac 地址从来不是地址，而是一种标记信息。路由是分组交换网络收敛和寻址的基础，IP 作为寻址信息的一部分是有必要的，但完整的路由过程大可不必。

路由过程分为 FEC 和查找，FEC 只需要加上标签（详见数据面封装的选择）以支持地址重叠，查找又分为 IP Routing 查找 BD、Next Hop Resolve 得到 FIB 的目标（来源于 RIB 的 Next Hop，没有则通过下一跳的代理 ARP 获得，overlay 模型的对称路由模式则是 Remote Mac）、Destination Lookup 得到 FIB 的逃出接口（来源于 RIB 的逃出接口，没有则根据下一跳递归查询，overlay 模式则是 Remote IP），显然我们只需要主机 FEC 和 Destination Lookup。

UCloud

为了支持 IP 地址重叠，使用 Mac 地址作为寻址信息，如前所示，Mac 只应当看做一种标记信息，不能和 VPLS 栽在一个坑里
数据面缺少基于 port 的标签映射信息，这导致转发规则成为了依赖于源信息的 P2M 虚链路，而不是基于目的信息的非广播多路访问，还要做额外的检验
为了模拟路由过程，多了 Next Hop Resolve 这一步
跨 VPC 逻辑不对，本质上应该是 IP Routing 的逻辑，而且放在东西向流量处理不是太合理，会逐渐与跨子网对于同子网同质化，无非是上面又多了一层

QCloud & Aliyun

基于 IP 寻址，但同样不依赖主机路由，细节不清楚。

理论上，基于附加标签的 IP 信息寻址，本地还原标记信息（Mac、Port 等）是最理想的方式。

Hoverboard 的 Gateway 解决了 NBMA 无法依靠也绝对不能 flood 的问题，但不应该丢掉 Learn 这样高效收敛的方式。控制面信息无非两类：LSA 和 NLRI，这里显然 NLRI 是最高效的方式，且没有任何隐患。那么，数据面学习的方式要好于控制面决定流量卸载的方式，即通过收到的报文获得网络可达性信息。至此，网络还少了一定的自愈性，比如当迁移后网络状态未达成一致时，Gateway 应该基于地址源信息和来源信息的不一致主动修复错误节点的转发信息，从而减少系统内发卡流量。此时，网络也具有了自愈性。

数据面封装的选择

VXLAN 是 VPLS 的产物，排除；Geneve 携带了更多的信息，比如 OVN 塞进了逻辑端口，VPLS + IRB 的产物，排除；GRE，腾讯使用的这个，但无论是在 NAT 穿越还是 ECMP Hash 上都不如 VXLAN（使用 UDP），排除；VXLAN-GPE，阿里使用的这个，没有前述的问题，但在支持一些特性上，比如 SFC 要再封装 NSH（直接基于 Port2Port 的策略转发增加了逻辑的复杂性），还有云网融合也不够友好，排除；MPLS，是 Peer2Peer 模式，泄露了寻址信息，但封装在 UDP 里就完美了，排除。所以，我的答案是——MPLSoUDP（且对 DCI 更友好，源路由成为可能）。

另外，无论选择哪种封装方式，里面携带的信息是寻址的必要条件，数据面需要维护 Port 到该信息的映射关系，亦或是从 Port 进来就封装必要的信息（中间关系状态的映射或者最终的标签）。

产品列表

只涉及 EW Traffic，nat/vpn/external/net space connection 等 NS Traffic 走异构网关。

Net Space
Service Pool
Address Pool
Service Function Chain
Domain Graph
Traffic Mirroring
Quality of Service and Explicit Congestion Notification

Net Space

相当于 VPC，但仅代表 DCN Spine-Leaf 交换矩阵内隔离出来的一部分网络资源，无论是跨地域还是本地域的 Net Space 间通信都属于另行组网，此时 IP 地址聚合。

分为两个属性：CS，client-server 的模式；P2P，预先下发 full-mesh 规则，不支持迁移。

Service Pool

相当于 Subnet，但不同于传统网络中子网的概念，1 个子网中 100 个 VM 和 100 个 VM 分布在 100 个子网中没有任何区别，要向用户屏蔽网络概念，Service Pool 的大小只跟业务 VM 需求量级和规划有关。

另外，具有一些特殊的 Service Pool，比如 Public Service。

Service Port

向外暴露可提供的端口，类似于安全组放行的入向端口。内部是全端口双向放行的，外部需要通过 Domain Graph 建立连通性。

Cluster

Bool 类型，可提供 HA 或者 LB 的服务。（建议数据面还是 mpls，实现更简单，LB 的选择可以依靠类似于 ovs 组表或者 lvs 的东西，为了解决状态维护的问题，中间不再引入新节点）

Address Pool

每个 Net Space 都有一份全量可用的地址空间，根据使用情况和 Service Pool 的 VM 预估量级自动打洞生成前缀供用户选择。

Service Function Chain

只支持 In-network 和 NAT 两种模式。

Domain Graph

形象展示给用户目前连通域的信息，也是下发策略的重要依据，本质上就是个以 Service Pool 为点，连通性为边的有向图。

连通性需要具有两个属性：Direction，依靠 ACL & CT 实现；Transitivity，依靠权值进行判断。

能否通信，即是否存在路径，连通域即为强连通分量。

Traffic Mirroring

流量镜像

Quality of Service and Explicit Congestion Notification

共享资源的必要手段，尤其涉及 DCI 的产品。

NCN-Draft