本文为《从60分到85分——SD-WAN进阶教程》的下篇，上篇请跳转http://www.c114.com.cn/tech/175/a1048761.html。
（续上文）Enterprise Oriented SD-WAN给企业带来的价值非常明显，在北美讯速地抢占了银行、零售、连锁等行业，包括很多世界500强的大型客户，2015年下半年开始，SD-WAN成为了业界炙手可热的新宠。由于SD-WAN对于上述一系列关键技术的利用，能够显著地提高Internet线路的QoE，这使得Internet线路在某些场景中，得以部分地代替MPLS线路在企业组网中的作用，因此降低了企业对于MPLS的依赖性。
因此，当时业界谈论最多的话题，就是“SD-WAN能否取代传统的MPLS VPN？”。MPLS VPN是全球各大运营商的支撑性业务，SD-WAN的突然崛起，迫使着大T们开始思考应对之策。
本文作为下篇将对“SP Oriented SD-WAN”进行介绍。首先，会介绍厂家给出的SDN-Gateway的方案。其次，将对运营商青睐的vCPE方案进行介绍。最后，简单地聊下MPLS VPN的优化问题。
二、SP Oriented SD-WAN
关于“SD-WAN能否取代传统的MPLS VPN”，其实这个问题的答案很明显。SD-WAN最大的价值之一，就是在Hybrid WAN的场景下更有效地去管理与使用WAN线路，帮助企业提高在WAN这一块的ROI。因此，SD-WAN的出发点并不是要对抗MPLS VPN，因此就谈不上要取代MPLS VPN，因为两者并不在一个层面上。
无论是从纸面上来看设计，还是从实践中看效果，SD-WAN确实实现了它所承诺的价值。运营商也很快地就看清楚了问题的本质，尽管SD-WAN客观上会降低企业对于MPLS VPN的需求，但这是技术演进的自然结果，另外SD-WAN在灵活性、自动化、应用感知、上云等方面相比于传统的技术方案，也有着不可比拟的优势。权衡之下，与其把SD-WAN放到对立面，倒不如想办法把其拉到统一的战线上，作为一个新的业务增长点。因此，运营商并没有排斥SD-WAN，而是对其表现出了相当开放的态度，这与很多人的设想是恰恰相反的。
SD-WAN的厂家们心里也很清楚，要做大事情就一定得把生态搞好，运营商作为生态中最关键的环节，有必要建立起一个融洽的合作模式。首先，纯Overlay的方案存在着一定的局限性，虽然说是Transport Independent，但是如果Transport的线路质量确实不行，那也是巧妇难为无米之炊，另外对于跨国企业来说，如果不用MPLS纯走Internet，那么基本上就约等于不能用。其次，运营商拥有着广泛的客户基础，业务的覆盖范围更广，无论在运营还是运维方面都有着巨大的优势，这正是SD-WAN厂家们最为欠缺的环节，一些大型的客户动辄就几千个分支，虽然技术上是ZTP + Cloud Managed，但是从渠道和服务的角度来说，就完全是另外一回事了。
双方一拍即合。第一种合作的思路是，运营商把厂家的方案买下来，然后自己来做渠道和服务，除了能够分一部分SD-WAN的利润外，更关键地是可以把各种WAN线路打包到方案中，为企业提供一站式、差异化的WAN解决方案。如果有足够实力的话，还可以对产品进行一些定制，把SD-WAN的能力嵌入到自己的业务系统当中。第一种思路，不需要对Enterprise Oriented SD-WAN的技术架构进行改动，同时有着清晰的盈利模式，对于厂家来说是零成本，对于运营商来说是一种快速进入市场的有效手段。
第二种思路，是对原有方案的架构进行调整。最初所设计的SD-WAN方案是Enterprise Oriented的，从技术上来看是找不到运营商位置的，如果要做一个SP Oriented的SD-WAN，就需要在方案中引入SP的角色。那么SP Oriented SD-WAN该怎么做呢？
1、SD-WAN Gateway
厂家给出的方案，是在运营商的POP点里面放SD-WAN Gateway，负责终结企业侧CPE发起的隧道，然后转发到运营商的IP/MPLS网络。在这种方案中，Enterprise SD-WAN中的CPE上所有能力都被保留了，不过端到端的Overlay变成了，两头的Last Mile用Overlay而Middle Mile交给运营商去做，如果运营商有能力的话就可以把MPLS VPN集成进去，如果短期集成不了MPLS VPN，Middle Mile这段用Overlay打过去也不是不可以。
实际上这是种很不错的思路，各方接受起来都很自然。从客户的角度来看，不需要去额外地购买的设备，而且传统的WAN设备也可以通过隧道接进去了，另外SD-WAN的运维也转交给运营商去做了。从厂家的角度来看，Enterprise Oriented的特色得以被保留，CPE仍然是高价值的产品，同时有效地解决了纯Overlay的局限性，另外通过SD-WAN Gateway也得以参与到运营商的组网中。从运营商的角度来看，SD-WAN Gateway不仅提供了对接MPLS的入口，另外也提供了更加灵活的接入方式，对于Last Mile不可达的Off-Net Customer，走Overlay做接入能够省去很多的麻烦事儿。
以SD-WAN Gateway为核心的SP Oriented SD-WAN，保留了Enterprise Oriented SD-WAN的所有能力。在此基础上，主要是提供了对多租户的支持，并在控制逻辑方面进行了相应的加强。
1.1 整体设计
对于运营商来说，SD-WAN Gateway作为业务的接入设备，在位置上和SR/PE并没有本质上的区别。对于Pure Play的SD-WAN厂家来说，他们在POP里面并没有存量的SR/PE，所以就只能推新的设备进去。形态上就是x86的盒子，相比于Enterprise Oriented SD-WAN方案中的CPE，SD-WAN Gateway作为不同客户流量的汇聚点，接口的速率和数量都会做相应的增强，而且由于它要负责大量隧道的终结，因此对CPU和内存的要求高很多，通常会需要专用的Crypto Accelerator。而对于传统的设备厂商来说，比如Juniper、ALU和华为，他们在POP里面有存量的SR/PE，这时候可以选择把SD-WAN Gateway以板卡的形式插到SR/PE的机框上，以避免多引入一个物理设备的麻烦。随着CORD在运营商中的推进，SD-WAN Gateway的形态开始逐渐向vCPE进行靠拢，关于vCPE等到后面CORD的部分再来做介绍。
控制器。从宏观的架构来看，除了Staging Server、Controller和Analytics以外，可能会需要AAA来专门做鉴权。从细节来看，由于多租户需求的出现，以及设备、拓扑复杂度的提高，使得控制器所用的数据模型以及业务流程都会发生一定的变化。从位置来看，On-Premise是不可行的，需要放到运营商自己的机房当中。通常是在地市级的核心机房里面，负责控制下属的各个接入机房中的SD-WAN Gateway，以及本地企业分支的CPE。
Portal也要做相应的调整，而且运营商很可能要自己来做定制，部署的位置也取决于运营商站在什么层面上来看待SD-WAN的业务，所以这里就不多说了。
1.2 多租户是怎么实现的？
企业侧接入SD-WAN Gateway的流量，需要能够与VRF进行关联。按厂家的意思就是用IPSec直接打进来，把接入网这一段OTT掉。在这种方式中，需要能够对IPSec流量关联VRF，大概有下面这几种办法：（1）用GREoverIPSec，为GRE口关联VRF；（2）用MPLSoverGREoverIPSec，用MPLS来关联；（3）用VxLANoverIPSec，通过VNI来关联VRF；（4）通过VTI口来关联VRF；（5）用ISAKMP Profile绑定VRF，识别SPI后直接关联VRF；（6）用私有的IPSec封装，在IPSec后面单独加VPN的字段。比较而言，从标准化程度来讲（1）是最好的，从封装效率上来讲（3）和（4）要好一些，不同厂家的实现中会有不同的选择。
不过，按运营商现有的接入网络来看，除IPSec以外，VLAN/QinQ/L2TP/GRE/MPLS VPN甚至是传输专线都有是有可能的，这对于SD-WAN Gateway的要求就比较高了。此时，传统的设备厂商相比于Pure Play的厂商就有明显的优势了
经过特定VRF的路由后，这里考虑跨地区的流量，流量要被送到目的站点所接入的SD-WAN Gateway上。根据实际情况，又有不同的方式：（1）如果SD-WAN Gateway间要走GRE/IPSec，就还是用上面刚刚所介绍的方法；（2）如果SD-WAN Gateway间要走MPLS VPN，且SD-WAN Gateway自己具备MPLS VPN的能力，这时可以直接给出向流量标记Service Label；（3）如果SD-WAN Gateway间要走MPLS VPN，但是SD-WAN Gateway并不具备MPLS VPN的能力，那么SD-WAN Gateway就要通过接口/子接口和PE做连接，同时与PE间起IGP多实例，或者BGP/MP-BGP打通路由，然后由PE来完成MPLS VPN的工作，这实际上可以看作是VRF-Lite的方案。
不仅是SD-WAN Gateway，整个系统实际上都需要进行多租户的改造。对于CPE来说，要接入SD-WAN Gateway，可能需要对特定的封装提供支持。对于控制器来说，要明确CPE所属的租户，以及SD-WAN Gateway上所接入的租户列表，然后在分发策略和路由的时候，需要能带着租户的信息下去。对于Portal来说，则要提供RBAC的能力，对不同账号的权限进行区分与隔离。多租户所带来的细节问题，还有很多很多，无法逐一而述了。
1.3 端到端的控制如何实现？
在Enterprise Oriented的方案中，控制器看待站点间的连接的角度很简单，两个设备+双向的隧道。在SP Oriented的方案中，由于控制器不仅要控制企业侧的CPE，还要控制运营商的SD-WAN Gateway，另外SD-WAN Gateway的引入还将路径切分成了多段，路由的控制上也很为复杂了。这些都对SP Oriented的控制器提出了很大的挑战，甚至可能需要在集中式和分布式间重新进行决策。
首先，端到端的拓扑就十分的复杂。简单来想，可能是（SD-WAN CPE—SD-WAN Gateway—SD-WAN CPE）做本地中继，可能是（SD-WAN CPE—SD-WAN Gateway—SD-WAN Gateway—SD-WAN CPE）做跨地区的隧道拼接，也不排除会做（SD-WAN CPE—N*SD-WAN Gateway—SD-WAN CPE）的POP点组网。如果有Non SD-WAN的设备打隧道接进来，这个设备的控制是不归控制器来管的，虽然控制的设备少了，但实际上控制器的建模却变得更加复杂了。如果Non SD-WAN设备接入SD-WAN Gateway，而SD-WAN CPE间不走SD-WAN Gateway直接打隧道，就更加混乱了。和路由目前来看，SP Oriented SD-WAN还没有一个标准的路由控制逻辑，只能是摸着石头过河。
在实际的部署中，SD-WAN Gateway不可能会是单点，相比于主备运营商更喜欢负载分担，那么还要考虑HA下的均衡问题。而且一个地区的POP点会有很多个，如何在POP点间进行流量的优化，也是一个重要的问题。
另外一个现实的问题是，运营商不可能完全OTT接入网和MPLS。Overlay在Internet上做接入，虽然在灵活性上有很大的优势，便于接入Off-Net的客户，但是对于本地的On-Net客户这种方式却不见得合适。对于一些运营商来说，CPE—BRAS—SD-WAN Gateway—SR/PE的流量模型并不符合路由的规范，而且BRAS、SD-WAN Gateway、SR/PE这三者间的形态关系也是千差万别，现网部署起来会遇到很多麻烦。所以说对于On-Net的客户，SD-WAN Gateway接入这一端更习惯于over在专线上。这样的话还要协同接入网的网管/控制器，如果再考虑与MPLS VPN网管/控制器的协同，整个SP Oriented SD-WAN的编排/控制系统会变得无比复杂。全场景、端到端的编排/控制，目前来看还有相当大的差距。
1.4 公网访问如何实现？
如果是要做Local DIA，那么分流在分支的CPE本地就完成了，流量模型是Branch CPE—BRAS—Internet。如果是要做Backhaul，是由总部/数据中心的CPE统一分流，流量模型的一种可能是Branch CPE—SD-WAN Gateway—HQ/DC CPE—Internet，另一种可能是直接Branch CPE—HQ/DC CPE—Internet。关于DIA和Backhaul，在Enterprise Oriented SD-WAN部分已经介绍过了，这里就不再赘述。
除了Local DIA和Backhaul以外，SP Oriented还提供了Regional Break Out的方式，流量模型是Branch CPE—SD-WAN Gateway—Internet，由SD-WAN Gateway完成公网和VPN流量的分流，公网流量可能还需要进一步地对国内流量和国际流量进行区分，以提供不同的路由策略。Regional Break Out要求SD-WAN Gateway能够提供NAT、安全和HQoS的相关能力，同时要求SD-WAN Gateway具有Internet的连通性。对于客户来说，Regional Break Out的优势在于，既可以避免Internet流量绕行总部/数据中心，降低了时延与带宽消耗，又可以通过SD-WAN Gateway为本地的多个分支集中地提供安全、WAAS这些服务，避免了以分支为单位去使用这些服务的成本。对于运营商来说，客户在本地所有分支的Internet业务可以集中地管理起来，比如对上下行带宽的统一分配。
至于公网流量如何才能从Branch CPE送到SD-WAN Gateway上，还是要看接入的方式是怎么样的。如果要Overlay在Internet上，那么控制器就要下发路由把公网流量通过隧道送给SD-WAN Gateway，此时流量模型实际上是Branch CPE—BRAS—SD-WAN Gateway—Internet，在现网中运营商不一定会愿意提供这种连接方式，这取决于运营商如何去看待BRAS和SD-WAN Gateway两者的关系。如果是over在专线上，路径上就不会出现BRAS，这时相当于一根线上同时跑了宽带和VPN两种业务，需要在计费方式上做好考虑。
2、vCPE
在运营商传统的POP点中，为了支撑话音、宽带、专线等不同专业的业务，需要采购大量专用的硬件设备，开放性和灵活性很差。在Cloud/NFV/SDN等新型架构的驱动下，全球各大运营商纷纷投身于POP点云化的重构进程中。POP点云化后，各类专用的硬件设备在形态上将被基于通用x86平台的VNF所替代，在架构上转发和控制得以分离解耦，这对于运营商具有巨大的价值。一方面在于开放性、灵活性等方面的提高，长期来看能够有效地降低成本。另一方面，运营商得以将各种增值服务的VNF以服务的形式提供给客户，这将是一笔相当可观的业务增收，也是破局“管道化”困境的有效方式。
在这一大背景下，SD-WAN的架构也得到了新的延伸，以vCPE为核心的解决方案开始占据SP Oriented SD-WAN的主流。这里有必要对vCPE的概念进行一下说明，从字面上来直观理解的话，vCPE应该是指一个与CPE具有相同功能的VNF，但实际上业界对于vCPE的定义并非如此。由于传统的CPE是一个泛指的概念，涉及路由、防火墙、WAAS等诸多技术，因此对CPE进行虚拟化的结果，通常并不是一个VNF，而是vRouter、vFW、vWAAS等多个VNF，它们各自完成一部分功能，然后通过服务链串接在一起，共同交付vCPE的能力。虽然在某些产品和语境下，vCPE可以指代一个特定的VNF，但是在通用语境下vCPE是指一套完整的解决方案。
至于SD-WAN与vCPE间的关系，从SD-WAN的角度来看：
- 如果SD-WAN CPE是基于x86的白盒，而且自身具备单独作为vCPE载体的能力，这时SD-WAN CPE就可以被称为vCPE，vCPE就是SD-WAN方案中的一个组件。
- 如果SD-WAN CPE以虚拟机的形态存在，那么可以作为vCPE方案中的一类VNF，这时可以说vCPE是SD-WAN方案中的一种实现手段。
- 如果在vCPE方案中，只提供vRouter、vFW等传统的VNF，并不提供SD-WAN VNF，那么vCPE和SD-WAN两者并无直接的联系。
如果理解起来仍然比较晦涩，那么换作vCPE的角度来看就清楚很多：
- 如果所有的能力都在企业边缘提供，称为Distributed vCPE，无论企业边缘的设备是不是SD WAN CPE。
- 如果所有的能力都在POP点提供，称为Centralized vCPE，无论提不提供SD-WAN VNF。
- 如果一部分能力在企业边缘提供，一部分能力在POP点提供，称为Hybrid vCPE，无论是否存在SD WAN CPE或者SD-WAN VNF。
可以看到的是，SD-WAN和vCPE并不存在严格的包含于被包含的关系。以这篇文章的出发点来说，可暂且把vCPE看作是SP-Oriented SD-WAN中的一种实现形式。下面就来对vCPE进行一个简单的介绍。
2.1 整体架构
一套完整的vCPE方案的实现需要Cloud、NFV和SDN技术的紧密协同。首先，要有一个x86的平台来提供虚拟化的能力，可以是在Distributed vCPE中的SD-WAN CPE上，也可以是在Centralized vCPE中的x86资源池中。其次，要有一套虚拟化的中间件+云管平台，如开源的KVM+OpenStack。然后，需要一套VNFM+NFVO，对VNF进行管理和编排。SDN这块，云POP点的控制器、SD-WAN的控制器，可能是同一套，也可能是两套，另外一些方案中还会包括接入网的网管/控制器。Portal就很难说了，完全取决于厂家的实现和运营商的集成。
vCPE是否要做成多租户的？除了厂家的实现以外，其实还取决于运营商的销售策略。如果是卖VNF的模式，那么一个实例只就能属于一个租户，这时不强制要求多租户。如果并不直接卖VNF，而是包装成网络能力来卖，这时做成多租户就比较划算了，不过要考虑好性能、容量、配额和扩缩容的问题。
实际上，vCPE就是POP点云化的一个企业级用例，上述vCPE的架构也就是POP点云化的架构。关于这套大的架构，本身就可以独立成一篇长文，这里不做深入的展开。
2.2 Distributed vCPE和Centralized vCPE
之前提到过，所有能力都在企业边缘提供的方式被称为Distributed vCPE，实际上Enterprise Oriented SD-WAN中的CPE很可能就是Distributed vCPE的一种表现形式，本地集成VNF，然后通过一些引流手段把它们串在一起。与之相对应的是Centralized vCPE，所有能力都位于POP点中，并由运营商以服务的形式来集中提供。那么，哪种方式更好一些呢？
先来看看市场方面的因素。从厂商的角度来看，如果其产品的能力比较全，就会倾向于Distributed的方式，把所有的功能都自己做在盒子里，如果其产品能力上有较大的缺口，那不可避免地就要做第三方集成，倾向性就会稍弱一些。从运营商的角度来看，一般会更倾向于Centralized的方式，一方面有利于运维，另一方面能够增强自身在企业组网中的地位。从客户的视角来看，Distributed是买硬件+服务，Centralized只需要买服务，如果Distributed和Centralized的使用体验一致，从成本来说自然是Centralized更好一些
不过，Centralized并不会完全地压倒Distributed。一来，目前运营商的POP点云化还处在早期的阶段，技术上距离成熟还有相当的一段距离。再者，一些VNF部署在企业边缘会获得更好的使用体验，比如WAAS。Hybrid vCPE在两者间取了一个平衡，一部分能力在企业边缘的盒子上，一部分能力在POP点中，由客户根据实际情况来自行订购。Hybrid的方式固然灵活，但是VNF的分散性对于运维来说是一个不小的挑战。
2.3 Centralized vCPE的流量模型
Centralized vCPE的目标是最大程度地简化企业侧的设备，最好是只留下二层的功能，把路由也移到POP点里面去。对于运营商来说，自然希望借此获得对于企业业务更加完整的控制权，对于一些中小型的客户来说，这避免了自己去维护路由的工作，实现网络的即插即用。因此，目前在很多的vCPE应用案例中，都会见到这种二层接入的方式。这时VPN和公网的流量都会发给POP点中的vCPE，vCPE不仅仅是虚拟化了企业侧的终端，实际上把BRAS和SR的一部分活儿也都一起给做了。
Centralized vCPE主要包括vRouter、vFW和vWAAS，在实际的部署中会有不同的串接顺序。当然，某些厂商也会将不同的能力集成到一个VNF中去实现，比如SD-WAN VNF很可能就是一个集多种能力于一身，这时流量的模型就要简单很多。这里考虑最常见的串接顺序vRouter—vFW下的流量模型，vFW采用路由模式。vRouter对流量的处理主要包括：（1）对流量进行识别；（2）为企业侧的接入设备分配IP地址；（3）对流量进行限速；（4）将流量送给vFW。在vFW对流量的处理主要包括：（1）对流量进行识别；（2）对公网流量和VPN流量进行分流；（3）执行安全策略；（4）公网流量送给NAT设备，VPN流量送给PE。
具体来看数据面的转发。目前NSH的应用还非常少见，这里不做分析。
- 客户接入vRouter这一段。可能的拓扑有很多，（L2 Switch—POP GW—vSwitch—vRouter）、（L2 Switch—POP GW—vRouter）、（L2 Switch—vSwitch—vRouter）、（L2 Switch—POP GW—vSwitch—vRouter）。由于要接入二层，因此可以选择VLAN/QinQ或者VxLAN，考虑到与物理拓扑解耦走VxLAN会稍好一些，一些节点上会需要做转换/拼接。
- vRouter到vFW这一段。如果在同一个节点上，拓扑是（vRouter—vSwitch—vFW），直接VLAN不用走隧道。如果不在一个节点上，拓扑就是（vRouter—vSwitch—vSwitch—vFW），vSwitch间走VxLAN就行。少数情况下，拓扑会是（vRouter—vFW），可以选择MPLSoverGRE，如果不支持MPLS可以用VRF Aware GRE。
- vFW到NAT/PE这一段。由于NAT/PE通常是物理设备，因此拓扑最好直接就是（vFW-NAT/PE），可以选择MPLSoverGRE，如果不支持MPLS可以用VRF Aware GRE。一些POP点中还会引入vNAT/vPE，这时就可以（vFW—vSwitch—vSwitch—vNAT/vPE）了。
可以看到的是，由于涉及到运营商的网络，因此底层的连接变得非常复杂，要针对现网的实际环境来做具体的方案设计。而且，由于拓扑没有一定固定的形态，因此对控制器的要求也很高，很可能需要做一些定制化的开发。
3. MPLS VPN的优化
从SD-WAN厂家的角度来看，只要把流量做好标记送给PE上就行了，PE间的打通并不属于SD-WAN要考虑的问题。不过对于运营商来说，MPLS VPN是企业广域网业务的基础，也是能够体现服务差异化的最关键环节。因此，运营商在设计SD-WAN业务的时候，一定会带上MPLS VPN一起做考虑。不过，传统的MPLS VPN所存在的一些局限性，使得它在与SD-WAN进行集成时显得很不协调。首先，开通周期太长，交付速度远远跟不上业务的需求。其次，带宽难以按需调整，客户只能按照峰值带宽的水平进行超买。另外，无法与云进行联动，企业入云的流量难以纳入到服务体系中。
快速开通的问题，并非单纯地引入SDN控制器对两端PE/ASBR做自动化配置那么简单。在运营商的传统体系下开通一个MPLS VPN，周期保守估计在45-90天，从开始填写订单到最后完成交付，其间要流转数十个步骤，其中向设备下发配置这个环节已经是由MPLS VPN网管一类的角色自动完成的，换上SDN控制器来配也没有任何本质的区别。真正的问题在于，传统的BOSS系统太过于臃肿，为保证系统的稳定运转，不仅流程复杂繁琐，而且很多步骤需要人工介入。因此破题的关键在于，运营商要对BOSS的架构和业务流程进行精简，否则任何网络层面的改进都是杯水车薪。
带宽按需调整，在BOSS层面也面临着同样的现实问题。单纯从网络的层面来讲，调带宽的方法要看MPLS VPN的QoS模型，如果是Diff-Serv的就是在PE上做限速和Mark，如果是Int-Serv恐怕就要去搞RSVP了。想法是好的，但在现实中运营商可能会遇到一些头疼的问题。首先，是调带宽这个动作极容易使网络变得不稳定，一旦客户调的时候影响了别人，很难去界定责任。其次，按需的粒度很难掌握，细了的话太影响收入，粗了很多时候对客户就失去吸引力了。另外，按需服务的模式对计费系统冲击太大，风险性需要进行谨慎的评估。
与云的联动不足，需要运营商与云提供商双方来共同解决。云机房通常会建设在城域网核心或者骨干网这一层面，通过DC Edge来接入运营商的Internet。随着云计算的逐步成熟，一些高价值的企业流量开始流向云端，然而Internet却难以为这部分流量提供足够的连接质量，引入MPLS VPN来解决这一问题是很自然的需求。对于运营商而言，如果不是市场策略上有什么额外的考虑，单纯从技术上来讲事情是很简单的，DC Edge就是CE，只要搞定它与PE间的接入和路由就可以了。
接入上没什么说的，裸纤/专线/VPN都可以，对于几个大的公有云，甚至可以直接把PE搬到DC Edge的机房去做直连，通过物理接口或者子接口来隔离租户。如果由于一些现实的因素，运营商和公有云间做接入存在困难，还可以通过第三方的IXP/CXP来进行中继。
路由这一块，由于要跨域一般就是静态路由或者BGP，如果是用静态路由，就是由控制器把路由配到DC Edge和PE上，如果是用BGP，那就需要控制器去配好Peering和Policy。从分工界面来看，DC Edge和云内部的网络由公有云提供商来负责，PE和企业侧的接入由运营商来负责，双方的控制器各自封装好API提供出来，上面的Portal或者编排器拆单后直接调用就可以了。对于IaaS流量来说，企业侧和云侧的网络在同一地址空间内，路由直接拉通就行了，但是对于SaaS流量来说，云一侧是公网的IP地址，因此路由是没法直接通的。因此，对于企业侧访问SaaS的流量，运营商还需要在PE送到DC Edge前做NAT，这是一个很容易被忽略的问题，特此进行提示。 
