编者按：本文系SDN私享汇在线技术分享系列，我们希望通过SDNLAB提供的平台传播知识，传递价值，欢迎加入我们的行列。
--------------------------------------------------------------------------------------------------
分享嘉宾：马绍文，Juniper亚太区产品总监。领导亚太区产品经理团队管理Routing/Switching/Security/Cloud产品线。跟欧美亚太主流OTT/SP架构师团队共同工作多年，积极参与业界SDN/NFV的发展，多次Apricot和其他亚太盛会上分享SDN/NFV等的主题演讲。最近的关注重点包括：Telco Cloud, MSDC, Automation和OTT 网络架构。对最新热门技术，EVPN/VXLAN，Segment Routing，Contrail/NorthStar SDN控制器, Appformix云运营优化软件均有独到见解。
--------------------------------------------------------------------------------------------------
1.介绍
云计算为了适应业务/APP 的快速开发和部署，会把网络分为两层：Overlay和Underlay网络。对于Underlay网络适用于传统的物理网络的自动化部署，提供基本的物理连通性，不需要经常变化网络拓扑等。对于Overlay网络来说，需要经常性的网络变更以适用于DevOps的要求，必须要引入SDN来控制Overlay网络，对于Overlay网络来说，也分为纯软件的(比如基于 vRouter)方案和软硬混合的方案(比如基于 TOR Switch上的EVPN+VxLAN)方案。
对应于Juniper的产品策略，Juniper除了坚持自研芯片，引领数据中心和核心边缘路由器的发展，帮助客户构建最强的 Underlay网络。同时发力NFV在网络的三个不同位置推动虚拟化：1) CPE演进，着力在SDWAN推出CSO(Contrail Service Orchestration)来颠覆企业网接入。2)Edge,推进Telco Cloud弹性云，在CORD小微数据中心里面推出MEC, vBNG, vPEC 适应无线边缘计算要求。 3)在云数据中心，采用多种VNF功能，例如DPI，FW等功能。
对于Underlay/Overlay网络，Juniper分别推出Northstar(北极星)和Contrail(飞机云，飞机划过天空带来的云)来进行Underlay和Overlay的SDN控制。
对于SDN(Software Defined Network)有很多不同的理解。大体上从最早的网管系统，自动化部署，监测网络状态，演变成：
A.通过软件API来直接控制路由器，比如ZTP自动化部署和基于Syslog/Event的变化而改变网络配置脚本Script等。
B.Underlay SDN
a.传统的SDN 理念，简化设备功能支持，引入集中式SDN控制器。交换机上仅仅支持OpenFlow Agent，统一通过 OpenFlow 控制器去下发转发表项，设备商在路由器/交换机上甚至可以不用实现动态路由协议。适合新建的DC等网络。
b.Hybrid(融合)SDN，保留设备上的大部分协议，同时引入全网 SDN 控制器。通过OpenFlow/PCEP/BGP/Segment Routing等等协议来指导设备进行路径规划。适合在现有网络中逐渐演进成SDN，充分利用现有设备能力。比如 NorthStar/WAE/ONOS/ODL 等等。
C.Overlay SDN
a.在 IP/MPLS Fabric Underlay基础的连通性之上，通过VXLAN， 或者EVPN/L3VPN等虚拟化技术，构造一层Overlay的网络，提供更灵活的连接性。 更方便的对接Openstack, K8S等云平台。Overlay控制器一般有一个大脑，来构造网络而不仅仅关注创建Tunnel。
b.基于硬件的Overlay：控制器直接控制交换机路由器，建立一张VXLAN，或者EVPN网络。比如国内某OTT尝试通过OpenFlow 驱动VXLAN来建立数据中心的Overlay，Cisco APIC也是把用户应用映射到不同的VXLAN Tunnel，并且扩展 VXLAN header 来实现应用QOS等功能。
c.基于软件的Overlay：控制器不控制物理设备，而是控制Hypervisor层面的vRouter/OvS等设备。比如VMware的NSX，通过 OVSDB在OVS上实现VXLAN隧道，Nuage通过OpenFlow来控制OVS。Contrail通过 XMPP(BGP)来控制vRouter实现L3VPN/EVPN，实现基于软件的Overlay。
d.最近Contrail 4.0版本，扩展Fabric Management模块来实现数据中心交换机的完全管理，通过Netconf/EVPN来管理Spine/Leaf交换机，实现基于硬件的Overlay控制。Contrail率先支持基于软件和硬件的Overlay SDN。
我们把业界常见的SDN控制器大致分为三类，可能不是很准确，很多控制器有新的进展：
1.关注路由器WAN的控制器
a.控制100+路由器节点
b.采用标准路由协议BGP/PCEP/Segment Routing etc
2.关注数据中心交换机的控制器
a.控制 1000+路由器节点
b.在两个TOR 交换机之间创建VTEP tunnel
c.采用OpenFlow等方式
3.关注Cloud的控制器
a.控制 10，000+虚拟路由器/虚拟交换机，vRouter/vSwitch
b.不再主要管理路由器/交换机。在hypervisor层面管控(vRouter/OVS)采用BGP/XMPP/OVSDB，创建vPE EVPN/L3VPN 网络。
业界最成功的SDN企业就是Google，采用四个不同的SDN控制器来优化网络。
1)B4 DCI数据中心广域网互联控制器。
2)Jupiter数据中心Fabric 控制器。
3)Andromeda虚拟化Overlay 控制器。
4)Espresso基于BGP的广域网Peering控制器 。
Google有强大的研发实力，可以定制化云主机VMM管理软件，定制化DCI交换机，定制化路由协议。但是Google的云计算网络部分不适用于第二家互联网公司，也不适用于运营商和企业客户。Juniper作为厂商来讲，不仅能够提供路由器/交换机/安全产品，同时我们提供两个SDN控制器来帮助管理 Overlay(Contrail)和 Underlay(North Star)网络。
对应Google的四个控制器(DC/Host/WAN/Peering)Juniper也有类似的控制器。不需要更改网络的Host/Switch/Routing Protocol,也能提供类似的功能。比如
•Andromeda---Contrail
•Jupiter--- Contrail/Network Director
•B4--- North Star
•Espresso--- North Star
以Google B4为例，这是个典型的 Hybrid(混合)型SDN，Google自己设计了新的B4控制器，部署在每个site的Server Cluster 上，运行所有的路由协议。每个switch上运行OpenFlow Agent 来补充转发表，提供更好的负载均衡多路径。使得全球 12个站点之间的链路利用率可以达到98%+。
微软SWAN广域网DCI控制器也是一个典型的Hybrid SDN，从最早的静态单层 MPLS Label构造的端到端隧道，到最新的基于BGP-TE SR的全球DCI互联解决方案。可以实现95%的跨数据中心链路利用率。
Google B4/Microsoft SWAN非常类似Juniper的North Star控制器。详细设计会另找时间给大家介绍。
2.Contrail Overlay SDN控制器架构
2.1 SDN演进史
最早采用Openflopw的SDN控制器有以下缺点：
1.每个flow的第一个packet上送到控制器来识别。
2.控制器需要被动的在路径上的每台 switch 来下发转发表项。
3.在中间物理设备上保留了太多的Per Tenant状态(没有 Overlay 的状态隔离)，交换机保留太多Flow静态信息，并且要支持OpenFlow，需要全网整体硬件升级。
4.最早 Hop-by-Hop OpenFlow解决方案，整个网络类似一个大的静态路由协议构造的网络，非常原始。导致高Latency，低扩展性，网络没有很好的鲁棒性。
Contrail在设计之初就采用了不同的技术路线，采用Overlay理念作为架构设计的关键：
1.报文不需要上送控制器，极大减轻了控制器的压力。
2.控制器主动下发Virtual Overlay vSwitch/vRouter。
3.依靠现有的协议来建立IP Fabric的连通性。Underlay拓扑变化不会影响Overlay。
4.Fabric不会保留任何Overlay Per-Tenant状态信息。
5.低时延，高扩展性，非常鲁棒的系统设计。 针对三种不同的SDN控制器，我们先讲讲最重要的Cloud控制器。
Google采用仙女座(Andromeda)控制器来进行网络虚拟化，管理虚机和 Docker。在数据中心的每一个Server上创建一个虚拟的 VMM(虚机管理系统)，通过GRE来构造Overlay网络，虚拟多个不同的VPN，把VM/Dockers 映射到不同的虚拟网络。每个VMM可以提供 Load balance/DDos/ACL/VPN 能力。
2.2 Contrail架构深入解析
Contrail SDN控制器实现跟Google仙女座(Andromeda)同样的功能。Contrail基本设计思想是：把每个数据中心服务器虚拟化出来一vRouter, 通过vRouter来实现类似EVPN/L3VPN功能。多个VM/Docker会连接到这个vRouter的不同的Tenent VRF。同时vRouter之间采用GRE/UDP/VXLAN做外层隧道, 采用内层标签来标识不同的 VRF。vRouter相当于传统L3VPN和EVPN的一个vPE 功能。vPE用户侧不再接入CE设备，而是为VM/Docker提供连接性。
通过 Orchestrator在Server上部署一个VM或者Docker：
1.首先给 VM/Docker POD分配IP地址，DNS 等等信息。在vRouter上创建 VRF/VSI， RT/RD等信息，上送回传到Contrail控制器。vRouter之间不需要协议通讯，vRouter仅仅跟Contrail 控制器进行控制平面的通信。
2.生成L3VPN/EVPN转发表，控制器知道现存的多个vRouter可能要跟新创建的vRouter共享相同的VRF/VSI，并且需要互相通讯，就通过XMPP来下发转发表信息(BGP NLRI内嵌到XMPP消息里)到另一台服务器上vRouter。vRouter之间仅仅建立转发平面的动态隧道。这样Server之间的M/Dockers 就可以通讯了。
3.控制器通过BGP/Netconf来通知GW Router来自动发布VM/Docker的IP prefix。这样Openstack/vCenter创建的VM/Docker就可以被外界来使用了。
简单的来讲，如果客户有一万台Server，部署了Contrail之后：
1.Contrail控制器相当于传统的路由器控制平面，承担计算Overlay拓扑，数据通道Tunnel建立等工作。相当于传统VPN的RR。
2.数据中心的Leaf/Spine交换机提供IP Clos无阻塞交换，相当于一个虚拟的交换矩阵，为控制器和vRouter之间提供背板交换。
3.vRouter/vSwitch跟Controller建立控制关系，vRouter之间建立数据 tunnel。每个vRouter相当于传统路由器的一个板卡。
4.部署Contrail SDN控制器之后，数据中心服务器里的很多vRouter一起组成了巨大的虚拟路由器系统(Network as a Router)。为数以万计的虚机/Dockers提供多租户隔离的VPN 网络连通。
接下来介绍 Contrail 网络服务。
•首先Contrail可以支持非常多的Orchestrator ，包括 Openstack, Kubernets, Marathon/Mesos, VMware vCenter, Amdocs,并且通过 Restful API支持很多定制化的Orchestrator，最近还支持AWS/GCP云服务等等。
•网络部分，Network 业务可以支持，L2/L3, IP Addressing, QOS, FW, Sec, LB, SVC Ch. Router Packet monitor, 实时分析等。
•对于设备控制：Contrail可以支持Juniper自身的交换机，也可以支持第三方的支持BGP/Netconf或者OVSDB的交换机。
•转发器Forwarder：可以支持 ESXI/KVM，Container，VPC GW等vRouter和Router/TOR的BMS。
Orchestrator可以通过RestAPI来自动化部署Contrail，大部分时间都可能不需要 Contrail GUI。对于TOR和BMS服务，Contrail支持OVSDB在TOR 上部署VXLAN。Contrail控制器也可以通过BGP/Netconf去控制MX GW router。
针对XMPP协议通讯，Juniper提出了L3VPN End-System draft，来实现从 RS/Controller下发BGP NRLI的转发表信息。比如这张图就可以看到 203.0.113.42/32 地址，分配了标签 10000，tunnel可选UDP/GRE,下一跳是192.0.2.1。基本上涵盖了一个BGP Prefix的所有的NRLI信息。
2.3 Contrail跟OpenStack的结合
典型的OpenStack驱动Contrail Network流程，可以看到通过Contrail WebUI支持Neutron Plugin来取代缺省的Compute Node里面的OVS。
vRouter在Hypervisor内核里面取代Linux Bridge或者OVS。可以提供 EVPN/L3VPN，还有Security Policy，NAT，Multicast, Mirroring, LB等功能。不需要Service Node来做L2/L3GW和routing功能。一个 Compute Node 里面可能有多个VRF表，每个VRF表可能连接一个或多个VM/Dockers。
对于Compute Node转发详情请参考下面的两张图：
VM会通过ARP找到VRF的Default GW，在VRF里面可以学习到对端的 Prefix，在两个Server之间跑MPLSoGRE/MPLSoUDP/VXLAN。
接下来请看一个实际的转发案例。如果你在Compute1上创建了VM-A，在另一台Compute2上创建VM-B。Contrail Control Node收到从Compute1上的vRouter Agent发过来的NRLI XMPP 信息,转发给相应的有通讯要求的另外一个Compute2，通过vRouter Agent来program VRF转发表。生成到 10.1.1.1 的路由表项。比如下一跳Server IP地址是 70.10.10.1，并且携带标签 39。
VM-B就使用MPLSoGRE隧道，找到Compute1，Compute1根据标签39来找到 VRF，然后查路由表转发给相应的VM-A。
相应的，你也可以采用EVPN来实现两个VM/Docker的互联。根据Type2/Type5 Message(XMPP)生成的MAC地址表。
通过Contrail WebUI可以查看路由转发表，上面部分是完整的Control Node的转发表，下半部分是其中的一个vRouter的转发表。
前面提到有了Contrail，DC GW和TOR可以自动通过Contrail 部署，现在版本支持Netconf来配置L3VPN/EVPN，并且支持OVSDB来配置TOR Switch(Juniper 或第三方，时间关系不详述)。
典型的配置请参考如上图，注意MX支持动态的MPLSoGRE/MPLSoUDP隧道建立方式。
2.4 Contrail进阶功能
Contrail能够支持Overlay/Underlay相关分析。物理设备拓扑可以通过 SNMP和LLDP发现。虚拟设备拓扑通过Openstack集成。
对于Underlay Path可以通过sFlow或者IPFIX来发现。下半部分可以看到根据每个flow可以映射到相应的Underlay。
Contrail vRouter上可以定义L4 Policy,可以允许/禁止某些主机，某些 App进行通讯。对于L7的业务链也可以支持。
有了Contrail Cloud SDN控制器，也非常容易做NFV的业务编排(Services Chaining)，我们给每个VNF的接口分配一个唯一的MPLS标签。如果要访问不同的物理或者虚拟化的VNF，只要找到对端的IP地址，并且携带这个MPLS标签，数据流量就会很容易的按照业务编排在不同的VM和 VNF之间实现业务链的编排。最近我们在讨论基于Segment Routing的业务编排。
Contrail还支持全部的性能增强模式。包括DPDK,SRIOV甚至还支持Smart NIC。
比如跟Affirmed Network和Netronome联合的解决方案中可以看到，我们可以把vRouter的转发部分下放到 Netronome，可以实现40G甚至200G的线速转发，同时释放之前用于转发的vCPU资源以支持更大业务带宽。
前面讲到的部分都是Contrail支持vRouter的转发，最近我们会支持 Contrail通过Device Manager来扩展支持自动配置Leaf/Spine交换机，还增加支持AWS/GCP的vRouter GW实现Hybrid Cloud统一策略，统一网络配置。
最近，Container部署是一个比较热门的话题。Contrail 4.0 所有控制器部分完全 Containerized，更方便于客户的快速部署。
Contrail有很多业务创新，比如最早支持Kubernets, BGPaaService等等。还拿 Google 举个例子。Google网络中大部分MicroService是用 Container部署的，很少有VM的应用。Google在一篇文章里提到，每个用户开始一个浏览器访问Google搜索，Google的后台会有70 个micro-service。每个星期在Google全球数据中心里，大概有 2 Billion 的 Container创建和销毁。Google开发了Kubernets去部署全球的 Container。但是Kubernets的开发者偏向APP应用层，在网络层面使用了 简单的Proxy来做Container的互联，太适用于大规模的Container部署。
Contrail在2014年支持Kubernets，适用我们自己的Contrail vRouter 替代Kubernets里面的Proxy，实现完整的VPN功能。我们的很多客户已经采用了Kubernets+Contrail来实现，比如LITHIUM用来实现SaaS，提供VM/Container/AWS Hybrid Cloud之间的资源自动调配。相关视频客户已经在2015年7月Post在Youtube上了。还有另一个客户TCP Cloud也用Kubernets+Contrail实现Smart City/IOT，去检测停车场/街灯的各类信息(temp, CO2, humidity, doppler)并且连接标准树莓Pi的IOT GW。
3.Telco Cloud和企业客户介绍
Juniper Contrail 客户大致分三类，企业私有云，运营商电信云，还有 SaaS/IaaS。其中运营商Telco Cloud的应用比如AT&T, DT等等，还有 NTT/Orange 采用Juniper的SDWAN/vCPE解决方案。
3.1 Contrail电信云解决方案
运营商转型的一个重点是要实现Telco Cloud，运营商的云化。
从上图可以看出，运营商网络的Time To Service部署，Operation开销和 Operation复杂性无法跟Cloud Provider相比。
传统运营商建网思路是以连接性为目的，买路由器，传输设备，提供管道，连通性。网络架构基 本不具备智能。
为了应对新业务的出现，很多业界Tier1 SP转变思路实现以超小(Micro)，Ultra Low Latency数据中心为网络建设的重点。比如为应对 VR/Health Care/自动驾驶等业务的低延时，大数据量应用(自动驾驶汽车需要视频识别，可能每秒钟产生1Gbps的流量)，必须要建设全分布式，超小型数据中心更加靠近终端用户。比如在北京的很多街道要部署微小的数据中心以指导自动驾驶汽车。
Telco Cloud 架构，把分布式的端局(CO)变成数据中心，可以支持虚拟化，网络分片等应用。同时运营商天然有足够的分布式端局CO资源提供 Telco Cloud的机房设施。把传统端局改造为大中小型数据中心，把网络引入智能，能够使得运营商提供跟OTT一样的甚至更好服务IOT/5G的最新应用的云平台。
Telco Cloud的一个重点就是如何管理全分布式的数据中心，很多Tier1 US/EMEA客户采用我们Juniper的Contrail来部署VNF 实现网络虚拟化。比如Telco Cloud里面实现vPGW，vSGW,vFW,vOLT 等等。
这是一个vEPC Telco Cloud实例。
3.2 Contrail私有云解决方案
首先介绍一下一个有名的英雄联盟LoL游戏公司。2011年被腾讯收入旗下，总交易金额16.79亿元人民币。2016 年营收超过10亿美金。同时每天在线玩家超过3000万人，同时峰值用户超过750万人。
RIOT游戏公司采用很多新技术，2017 年一月，他们详细介绍了采用 Contrail和Docker来自动化部署北美、欧洲和亚太三个大型数据中心。
为了在私有云和AWS公有云还有第三方的Partner(腾讯/Garena)网络架构上共同开发游戏，他们自主开发了rCluster编排器，再加上Contrail虚拟网络和Docker助力，极大方便了程序员软件开发。并且集成了防止DDoS攻击的Containerized网络功能。
详细信息请参考：https://engineering.riotgames.com/news/running-online-services-riot-part-iii
案例部分最后分享一个商用SDN控制器的排名。
虽然这个排行榜把大中小型客户，和Underlay/Overlay网络SDN控制器揉在了一起，也可以看出来 Contrail 在市场上的领先地位。
4.总结
最后介绍一下Contrail的愿景，Contrail首先聚焦在连通性，通过 EVPN/L3VPN来提供CPE，数据中心虚拟化，Telco Cloud 5G MEC CO，并且支持 Public Cloud Security Connection，提供 Massive IOT 设备接入。
然后聚焦提升vRouter 的安全性，包括L4和Micro Service隔离的安全性等等。
最后提供电信云，私有云，公有云统一的管理界面，统一的运营界面，统一的大数据分析界面。 连接公有云，私有云和混合云的 Multi-Cloud策略。
最早SDN起源于数据中心的OpenFlow，目标是通过动态配置管理上千台 TOR/Server，建立连通性。数据中心基于简单拓扑，物理冗余性，交换机功能简单，网络超配，SDN Controller不大需要关心网络资源，流量状况。Automation(自动化)成为SDN 控制器的最主要特性。
随着SDN影响越来越大，SDWAN, WAN SDN, Cloud SDN需要SDN/NFV控制器来更好的理解流量和资源分配状况,这时候需要通过Openconfig/gRPC搜集 Telemetry信息，上送控制器。原始的信息很难被控制器理解，越来越多厂家在SDN控制器之上加入机器学习，人工智能部分，更好的指导控制器进行网络自动化。
举个例子，Juniper最新Appformix解决方案，用来优化Openstack云部署环境，采用了机器学习，当部署新的VM/Docker时，Appformix注意到，尽管某个Server的CPU负载很低(只有 20%)但是那些L3 Cache资源已经不足，Appformix会进行迁移,把现有的VM 移到L3 Cache 充足 Server。当有个新的 VM/Docker部署要求时，最简单的就是给他分配一个新的Server，但是新的VM/Docker也许和现有的一个VM有很多交互，share相同的资源，如果把新的 VM/Docker部署在现有的Server上，而不是每次都分配新的Server，可能整个应用更流畅。
从上面的例子可以看出来，现有的SDN控制器仅仅是算是机械手，引入人工智能，引入Telemetry更好的理解网络。形成一个闭环的SDN自愈合控制系统。
从前面的介绍可知：
•通过 API/Netconf/OpenFlow来做自动化运维仅仅是SDN的初级阶段。
•发展为管理现有网络设备为主的Underlay SDN架构，一般采用Hybrid SDN在现有设备上构建不同的隧道来做流量工程调度。
•Overlay SDN控制器，在Fabric IP可达基础之上，Overlay SDN控制器模拟VPN RR功能，引入网络智能大脑，创造了一层虚拟的网络，更灵活的部署云计算业务，从SD-WAN到数据中心云化，引领了SDN发展的浪潮。
•Juniper Contrail从Overlay SDN入手，逐渐增加Fabric Management 的部分，引领了业界SDN 发展的潮流。
Juniper的网络远景是打造『自驱动的网络架构』-“Self-Driving Network”
5.Acronyms
Q&A
Q1：如果是一万台server vrouter是full mesh么?如果是 怎么解决这么对连接
A1：每个server里面的vRouter只跟Controller通讯交换控制信息。转发信息如果属于同一个VPN，vRouter可以动态的发送MPLSoGRE, MPLSoUDP，VXLAN报文
Q2：怎么从传统网络向Sdn网络迁移，或者说向Sdn网络过渡，我们应该怎么准备
A2：传统网络向SDN迁移，要考虑为什么，如果是要云化，公有云，私有云，IaaS/PaaS等等，需要考虑Overlay SDN控制器，这时候一般是在server或者TOR上创建Overlay网络。
如果仅仅做流量工程，类似Google B4，Microsoft SWAN，建议考虑Juniper North Star这种全网视角，创建tunnel来调优流量的Underlay SDN控制器。如果SDWAN，企业网接入，也需要Overlay SDN
Q3：最直接的，我的企业现在业务变化量不大，那么我向Sdn网络迁移的收益在哪里?
A：这个问题，可能跟企业目标有关，如果不想提供云服务，也不需要优化网络路径，一般Automation，就能解决很大问题，我们看很多运营商，比如Telstra他们对网络的Audit，自动运维等很有需求。
Q4：Q：在有限的underlay网络下，overlay网络的qos如何保证?还是传统的diffserv么?大规模网络的admission control 如何实现?
A4：在Overlay网络中，现在数据中心中部署居多，很少跨越广域网，所以QOS要求不高，但是Telco Cloud要跨越广域网，多个数据中心的时候，需要vRouter支持QoS，juniper Contrail vRouter可以支持MPLSoUDP等的QoS功能。
Q5：All Juniper device can be controlled by the Contrail controller? or only some Juniper device can be managed by controller?
A5：现在juniper的contrail Focus在vRouter上，ToR switch QFX5000系列也支持OVSDB的配置管理。MX/vMX支持自动GW部署，比如自动MPLSoUDP tunnel等。我们将很快release Fabric Management，可以管理几乎全部的juniper router/switch..甚至第三方的设备。
Q6：OpenContrail跟northstar有何区别?刚刚的分享发现Contrail把2层也管了
A6：Contrail是overlay SDN，Northstar是定位hybrid underlay SDN
Q7：部署openstack with opencontrail的时候， vrouter是怎么部署的?先用kvm启动 还是用openstack的命令启动的?
A7：nova创建虚机，neutron创建端口，nova scheduler去找一台physical server，然后通知vrouter agent，启动KVM。很复杂的一个orchestrator流程
Q8：现在我们的Sdn解决方案国内有没有落地的案例 比如金融行业或者能源行业 ?国外又没有金融和能源行业的案例?
A8：我们在金融行业，有一些证券交易所，还有一些银行保险公司的案例
Q9：“原始的信息很难被控制器理解，越来越多厂家在SDN控制器之上加入机器学习，人工智能部分，更好的指导控制器进行网络自动化。”这里引入的机器学习or人工智能部分，是指对策略做的预判吗。打个比方，SD-WAN和DCI的TE在这里controller怎么去对接的
A9：SDWAN解决的问题，是多个出口，类似于Google Espresso Peering的解决方案，因为是出去internet的流量，比较容易控制，一般基于AppQoS就能解决的很好。前面说的是Egress Peering，另一类问题，ingress peering进到运营商或企业网的流量，需要根据流量情况来预判断，同时控制手段单一，比如仅仅能BGP Prepend AS，这时候需要ML/AI SD-WAN和DCI的对接，这种端到端的保证，只能通过AppQoS/Probe去多选一
Q10：vRouter的东西向流量怎么采集到分析集群，有什么制约?
A10：Contrail vRouter做流量镜像非常容易，我们在contrail service里面配置端口的镜像，支持ACL镜像，并且通过MPLSoUDP发送到采集的VM。
Q11：juniper南向会坚持使用ovsdb，还是会逐步加入对netconf等其他的支持;
A11：我们还会支持OVSDB，也会增加很多netconf支持。
Q12：juniper有没有企业用户对边缘CPE设备的低成本解决方案，毕竟很多大型企业的边缘节点往往峰值流量也小于10m，不可能动辄买几万元的设备去部署SDN
A12：我们有SDWAN解决方案，之前方案有些欠缺，最新的版本有了很大的改进，比如支持APPQoS等。。请联系销售团队进行最新版本的demo
Q13：求问contrail用的什么协议对网络telemetry的
A13：现在Contrail支持netflow，我们正在集成Appformix功能来采集Telemtry信息。很快就会支持。
Q14：这里一直强调的“Overlay”我是不是可以理解为，Contrail和“数据平面”交互区别于传统的：1. 通讯方式是XMPP协议，传统的是ovsdb之类的，2. 通讯内容的是“路由表”(或者是通过BGP传递的VxLAN转发表)，传统的是流表(Flow)。所以这是不是Contrail区别于其他Controller的关键?
A14：选择XMPP而不是BGP的原因我介绍过，XMPP是gtalk选用的大规模通讯机制，XMPP里面携带BGP NLRI就是这种折中，contrail controller跟vrouter agent之间通过XMPP来传递BGP路由表信息， vrouter agent下发转发表到vrouter forwarder，Contrail控制器相当于一个路由反射器，有全网的拓扑大脑。这是一个contrail区别于其他SDN控制器的主要原因。
Q15：和Cisco的APIC相比 Juniper的方案有什么优势?
A15：思科的是hardware overlay方式，juniper contrail可以支持Software和Hardware Overlay
Q16：对于sdwan场景，目前telemetry只在CPE上吧，采集的流级信息不是network-wide的，是否足够支撑故障诊断，contrail在这方面是怎么考虑的
A16：SDWAN场景，Telemetry可以在CPE上采集端到端SLA，然后做路径选择。。可以通过APP SLA monitor来实现
