大家好。我叫陈鼎，是来自于新华三集团中国区运营商解决方案部的，我属于市场体系，我的主要工作是和各省公司的专家讨论本省的演进和未来规划的建议，并且和三大运营商集团研究院各位专家一起请教，来做一些规范上的方向上的研究。今天借这样的机会我是希望能够和在座的各位专家和同事一起来分享华三在云网融合的时代里，我们在CORD方向上的想法和使用的实践，我们其实也遇到了一些问题，能够在这样的机会和大家一起探讨分享一下。
新华三一直致力于和运营商探索我们重构的一些创新方向上的方案和我们重构如何去演进。其实在这块我们对于网络重构是有和CORD组织，包括三大运营商有一些共识的地方。就是在新的网络情况下，它会有两个关键：一个是泛载的超宽网络，成为互联的，会是一个连接的基础。第二个方向，推进面向DC为核心的网络重构。在座的很多应该是运营商行业的各位专家，在我们原来的网络规划里更多的是面向于带宽，面向管道的业务来做的一些工作。现在其实我们更多的是希望在做转型的过程中能够做一些面向业务方向的转型，将我们能够提供的服务从传统的管道，从我们传统的带宽，能够更多的延伸到无论是家庭客户，还是我们的企业客户的更深的一步。比如说它的IT业务，或者家庭的更多样化的云的服务。这个是我们在重构，在转型的一个业务驱动力。在这里实际上非常关键的一点，就是业务从哪里来？业务部署在哪里？业务发源于哪里？去到用户侧那里是没错儿的，但是现在有很多更关注到的是，我们要做的是DC这块我们应该怎么样部署一些相应的业务，或者我们传统的一些电信的网源或者电信云如何做减法，或者去做拆解，去做解耦这样的一些工作。这块是华三在重构的过程当中所希望能够关注的关键点所在。
还提到的，今天更多讲到的是我们的实践，华三是讲究实践的公司，就是行动派，可能在很多的很多省里，如果大家来自省公司的话会更多的看到华三的身影，我们非常愿意合运营商一起一真正的来聚焦一个项目，来真正做一些项目，就是我们来真正的讨论现有的网络如何向新的网络方向，向CORD方向去进行重构，如何去做这样的一些事情，今天我们希望能够更多的发现一些，在我们做这些事情的过程当中遇到的中国运营商所普遍遇到的问题。
我们前期在云网融合的重构的过程中做了两个方向上的事情，其实从整体解决方案上来讲的话，包括华三提供的一些产品和解决方案，我们是希望能够覆盖到包括E CORD，M CORD，R CORD。M CORD我们更关注到运营商的方面，E和R CORD我们更关注给各个省公司的建设部门。在两方面在这里看到的，一个是在新型城域网主要关注的是R CORD，就是如何用DC技术来对电信网源进行拆解和重构。这个命题实际上对所有的运营商，尤其中国运营商我们的包袱还是挺重的。我们以前作为硬件厂家所提供的产品的能力或者功能是相当的复杂的，所以在重构的过程中来做NFE电信云的时候，我们的切入点其实是需要思考一下的。华三在前期的工作里，从2014年一直到2017年今年上半年我们很多的事情是在做两个方向上的事情：包括跟联通以及跟电信，还有包括跟移动的省内合作来看的化有两方面：一，对于城域网边缘的业务控制层，就是BNG这个网源，把它的渠道压力下载到电信云的资源池里。第二个方向，是面向我在做大流量的视频流的，就是和视频业务发展过程当中，对于需要比较大的投入做扩容的BNG设备，它的流量压力我们把它控制面和转发综合分离的形态来实现我的IPTV业务，比如像4K，向未来发展的方向过程中，这个流量对BNG设备的一个消耗。这块是目前我们看到从低级BUG机房改造中，可能离开时把机房梳理完毕，有100个机房可以完成第一期的改造，在这个机房首先加载什么样的R POT的业务呢？这块是前期在省内的切入点入手的东西。这个是我们R CORD部分的目标或者前期的工作。
第二部分是E CORD，这个主要面向我们的政企用户，尤其在中国目前中小企业创业是比较艰难，但是好在有很多的政策，包括跟国务院，跟运营商一起来做的政策，包括我们聚焦在双创园区等等这些机会，或者这些机遇，又恰逢我们在做DC化的改造，在做CORD的改造，实际上在中国的市场里我们已经看到，包括像上海电信、江苏电信前期做的，就是面向中小型企业的一个E CORD的改造。以前或者包括阿里和腾讯它们能够，甚至亚马逊它们能够为我们中小型企业提供的服务是在云端的，可能跨越城域网，跨域骨干，在中国可能跨越两个运营商。这两件的服务质量对OTT厂家或者互联网来讲没有办法端到端给你做保障的，但是运营商做这个的话，它在政企行业不一样的及我们的优势是云网能融合在一起的。尤其我们现在做了COG机房改造之后，有一个很大的优势在于我们的接入资源和我们的边缘计算的能力是可以被我所用，被我综合起来来做的。所以这对运营商来讲，就是对整个运营商市场来讲我觉得是一个非常大的，跟我们OTT或者互联竞争来讲的话是一个很大的优势，我能够做到一跳入云，而且是以低时延，高带宽的方案来入云。还有一个我们能够在这边做到大二层的一跳入云，这里可以为企业开展，比如像虚拟桌面，实时的一些通信，还有打卡等等一系列的工作，这块也是在E CORD这个部分里华三是希望能够努力和未来持续推进的一个方向。
刚才介绍了一下华三在过去的两年我们做的一些事情，一个是在R CORD领域，一个是在E CORD领域，我们希望能够和运营商有些更深入下去探索的。在今天的介绍里我在接下来胶片里会关注到新兴全域网，这个就是R CORD部分的内容。其实我觉得这张胶片无论是电信，还是联通，我们基本上有一个共识，就是华三对于新兴城域网重构目标是按照这个方向走的，我们看到集团的一些规范也基本上是跟我们有这样的同样的意识，或者说同样的想法。当然这里也是很多部分是借鉴了或者是吸收了CORD组织的一些想法，我觉得大家在这个思路上面是趋同的。就是从用户的接入网尽可能的简单，无论是CPE还是ORT，只要是接入设备，大量存在的成千上万的远端的设备都尽量让它简单，它只做一些简单的工作，复杂的，需要维护的一些配置的事情，甚至是业务的东西，我们尽量希望它到边缘DC或者核心DC这块来解决。也就是把它拿到运营商侧来。远端部署的成千上万的设备，在运营商这儿如果真的坏了，我叫一个人工替换掉就可以了。这就是基本大家的思路是一致的。
在华三其实是有一些关键点的，这个关键点在于接入网进来后到DC怎么去？到DC怎么去我们这儿引入了边缘的汇聚分流层的形态或者设备。但实际上它跟我们现有的城域网中所用到的硬件设备是可以一样的，或者它通过升级的方式是可以支持的。它要做的事情在我们后面的方案介绍到，很简单，它不需要有太多的配置的更改，配置的协调等等这些东西，它要做的一个事情，就是将城域网接入层过来，用来标记用户和标记业务的QNQ识别之后，根据你的规则进入到NHI隧道，然后打上VNR标识。通过这台设备或者这个层次部署的设备进入到云，一跳入云，无论底层是怎么样连接的都没有关系，或者在DC内部进行了网还是怎么样，都没关系，我是直接跳入你业务的对端做了Overlay工作。这个设备层次的形态和架构不仅仅应用在R CORD，同样也会应用在E CORD里。之后我们会讲到如何区分家庭宽待用户和政企用户在VNR分配不同，但是其他方向是类似的。至于进入DC内部进行业务处理的过程当中，它怎么样区分业务，怎么样给不同的QAS和保障，实际上是在业务内部进行处理的。
进入到DC之内我们也会把它进行一些划分，但是未来我觉得也跟之前，也听过AT&T专家的建议，他们之前也考虑电信云或者叫电信级的NFC网源这些资源池的云和面向政企或者IT业务，不是我们自己内部自营的私有云，是面向政企的这些内容，这块能不能在云的层面上，在OpenStack这个层次上合一？其实我们理想是合一的，但是在目前阶段，这个云对底层的，还有OpenStack有一些要求，所以在目前的方案实施还是分开的。包括我们县网的，像南方电信有些省份我们做的案例里，其实也是把它进行分开。
在CORD里谈到的更多的是边缘DC，在我们这里实际上如果把它放到一个真正的城域网里我们分了两级DC，在边缘DC和核心DC这块有业务部署的区分，也有一些管理的层次，基本上是上升到核心DC，边缘DC更多的只是做一些大转发，或者时延要求比较高的这样一些业务去部署在它的边缘DC。最上层会有控制器以及业务编排器去做整个业务的串通。这是华三目前对城域网重构的整体的目标架构。
刚才也提到了我们有两级DC在一个城域范围内，这两级DC怎么区分呢？就是它有层级关系吗，它还是有业务部署的一些划分的要求呢？实际上在我们县网实施里，会在县网业务匹配的时候会有这个问题。像IPTV的转发面，还有像PPOE的，因为我们现在宽待上网基本都是PPOE，这个可能跟海外有些不一样，这是我们的国情。IPTV和PPOE业务转发面我们会放到边缘的DC内部，我们一会儿会介绍到它可以是X86架构的，也可以是一种硬件的专有芯片形态的，这个是没有关系的，就是对整个架构我不关注这个，只不过面对不同业务我会选择更适合的转发面，这个是有可能的。
在区域DC或者本地DC和核心DC会部署电信云当中业务适合集中布放的，尤其像ITMS这些，还有Lens业务，像面临政企，像电力抄表，像南方电信在跟电力行业谈，这些垂直行业在谈，我的电力抄表收费的终端通过接入网接入之后，也可能是无线接入进来，要到电力系统之前去认证，这个时候会有硬件的设备部署，现在也是放到电信云资源池进行部署。这部分业务有共性，就是它要去的业务的处理点，这个服务的设备或者这些服务的网络，都是在集中布放的。所以在集中布放的类型会放到市一级的核心，甚至于在南方电信，像江西这样的省份，我们是省一级来集中布放，包括TMS，Lens等业务，放到省一级统一管理，来体现云资源一个最大的效能。在市一级或者省一级还会部署管理这层次的东西，在现在的方案里华三可以提供管理整体的组件，一些网源，同时可以兼容第三方，在省里部署的时候也做对接，做业务的开通，Dbase的加载等等工作。最后我觉得归有一个大的电信云的统一管理或者运营的平台，包括它的界面，包括跟后台的工单派单系统，跟营业厅的这些系统，或者跟CRM系统，甚至是运维的一些部分的东西都会去进行互通。
现在R CORD方案在县网，就是在中国的运营商，包括像山东联通，江苏电信，浙江电信，四川移动都已经开始部署，像山东联通走的非常靠前，基本上我们是在山东第三大目前的，山东联通本身第三大的DC中心，就是在枣庄的局点我们部署了我们华三的这套R CORD的解决方案，就是Dbase这块解决方案。在江苏也是比较典型的，在无锡整个城域网范围内，我们甚至根据前期的CO机房的梳理规划，总结出来若干个机房是适合于做DC化改造的。因为运营商机房条件真的是差别很大，所以我们一开始是需要梳理的到底哪些适合做DC化改造，哪些不适合。做DC化改造的机房我们也进行了规划，它面向是多大规模的接入用户群体，目前在无锡我们基本上规划的是20万用户的边缘机房覆盖的能力。当前这20万用户主要考虑的是家庭宽待用户，当然它的DC整个规划容量是规划的R-CORD、E-CORD、M-CORD整体的。
刚才我介绍的华三和各个运营商所做的我们县网的一些架构上的想法，接下来我想深入一些细节的问题，首先，我刚才提到的在我们接入侧异常简单，它就是一个盒子，到DC的时候如何进DC，我如何把它进行业务的分流，我的城域网接入侧的信息如何能够带到DC内部来，这些信息还有没有用？我想这个问题是应该所有做中国的运营商的，包括运维，包括网发的同事都会第一个要去考虑的问题。因为接入网真的是很大，很烦，前期的规划有可能很乱，这都有可能。一个简单的例子，以前城域网架构里，接入侧ORT过来，有拓扑照相机，前期没有梳理的有两级，梳理过有一级或者没有，直接连Base端口了。在这里每个OLT上面的规划，到Base端口是终结掉的。这些信息是通过Nas或者通过Base端口以及下面的信息带给后台业务系统去做用户的精确绑定，做物理位置定位的及如果按照我们所的通过引流方式进入DC内部之后，面向的是资源池，面向一堆服务器或者虚机的时候这些信息还要不要保留？当然有一种说法，我业务开通的时候或者业务发放的时候，产品规划的时候可以不要这个东西。这是一种思路，这个没错儿，我觉得这时最简化的思路。但是我觉得中国的运营商要做这件事情的话，要决策的部门很多，而且又涉及到前期的产品发放的问题，其实对于我们解决方案提供商来讲是面临的一个挑战。现在解决方法，实际上还保留接入网Q&Q规划，通过XLan把Q&Q信息代入进来进入虚机，这些信息就是就是认证的体系。这些认证的体系再重新把这些封装，解封装，就是把解封装之后进行用户的认证，这二层的信息，就是用户接入侧的二层信息会全部带到Ebase或者认证系统来。这个Ebase其实后台和后台，就是3A之间的交互有两种选择：一种是和3A之间交互不变，会把这些信息直接保留在Ebase里，它还是延用原来的，比如说对于城域网Pvlan等的定义。还有一种是把VXlan和Q&Q信息通过扩展字段来报给3A。两种方法：后面方法更精细，但是3A要跟我交互改造的，其实有的省已经跟3A厂家在沟通，在改了，测试版本我们已经可以做这些事情了。当然3A我觉得还是，对于我来讲真的是跟省公司的好多部门一起来共同这个问题的时候就会变得巨复杂。当然，前一种方法会件大，就是说我们也是跨专业的，IT专业和后台专业，跨专业事情不好协调，就在内部协调，IT专业能解决的问题不放到和3A交互的过程里，这样的方法也是可以的。
我们一起来看一下我怎么样进VXlan的方案，当然进VXlan方案如果从实验室的角度，或者是从纯技术的角度可以有很多，我愿意根据内层标签怎么打，还是外层标签怎么打，都可以这么去分配，但是我们要注意到的一点，就是说谁来做了这个VXlan，就是打VXlan标签的事情，是这样一个边缘大容量统一转发的设备。这个设备目前来讲我们的能力其实是支持到K级别的，就是大一点的芯片大概8K、9KVXlan的空间。这不是华三的情况，我说的是业界普遍情况，就是小一点的大概4K标签容量。所以我们需要看到的一点是，在做标签的分配的时候，面向于家庭用户，我们其实每个OLT，每个业务给它分了一个外层的标签。刚才说了，就是说接入网过来的信息都是带到VXlan里，所以对Base上面认证的系统看到了更多的系统。在这里只需要把OLT和业务区分开就可以了。比如这台设备或者这个覆盖的设备接了十台OLT，有中国电信，中国联通，每个线网用户有四个Vlan，占了四个标签，在我们这个设备上只需要这么多OLT乘以有多少业务就行了。一般来讲，在中国的运营商的覆盖范围内的话，一个这类型的设备覆盖的OLT数量，少则十这种概念的台数，多则三十这种的数量。所以基本可以看到市面上做硬件厂家的专用硬件设备都可以支持这样你需要的容量空间的，因为无外乎最多就是120个标签的要求。
还有一个政企业务，很典型的一个方案，就是说用户的接入侧过来以后要建边缘DC，尤其像我们现在在数据中心最多的VPC方案。这个是需要跟你的VPC业务打通的，就是内部的BNI分配方案是打通的。所以在这里我们基本按照每用户一个BNI标识给打的。那么 需要看这个层次化的设备它下面覆盖的政企用户数的数量是多少，基本上是按照PUPVXLAN或者PUPVN的方式分配的。目前看政企容量K级别是够用的，来做这样用户的覆盖。这个是我们来讨论的第一个问题，就是从接入网谈起，逐个往上走。接入网谈的就是如何从QInQ到VxLan，还有原来QinQ每个省都有自己的执行规范，我的Vxlan加入QinQ的话还有一个新的规范，我们现在在实施的省已经开始做，或者已经做了这件事情。像江苏电信走的比较快，而且在这方面很有自己的思路，所以它们已经有省的自行规范来做BNI的定义和分配，虽然BNI分配有16兆，但是我们要注意的是设备能够支持到的表现空间是多少。第二个，如何去利用这个16兆，它有可能是全局概念的东西。
第二，从接入网过来到了边缘DC，之后我们要做的工作就是来看一看当前的NFV它的能力是什么样的情况，当然测试的环境我们列出来了，目前的测试环境用的英特尔的2630，VC两入八核的服务器，合2.4G，两块英特尔的网卡，然后出两个万兆端口。这个服务器是我们定制化服务器里挑的一款，就是属于中国电信服务器挑的一个基础设施的环境，在硬件上面我们起了两个虚机，通过KVM开源的，还有华三自己的KVM，其实一起做了一个测试。这里拿的数据是开源的KVM上面跑的数据。我们在这上面起了两个虚机，网卡通过SLV网卡绑定上来的。在这里我们其实测了五类业务，还有一些Vlase业务前期测了没有整合进来，因为测试环境不一样，没法儿进行对比。在这个测试有POP业务，IPTV业务，还有IP专线的业务，就是面向大客户的专线，还有综合业务，综合业务就是前面四个业务按照一定的比例进行叠加。这里有一个问题，因为今天来的很多专家和同仁很有可能是产业界的，我想说的是任何时候去讲你的NFE性能的时候一定要带上你的流量模型。我这是明确的告诉大家，我的POP是384字节，IPTU在4节，ITMBP要求64字节，小包，我们是要求每用户大概是89K，IP专线目前我们统计的线网主要的业务的流量模型是2.6兆/用户，字节数按照384走。综合业务其实就是业务叠加，业务叠加里各个研究院有自己的业务测试模型，我们这里的测试模型实际上是拿线网抓的，就是看线网的流行模型是什么样的。基本在我们这里一万个用户里，比如说并发率是按照50%来算它的PPOE宽待上网用户，就是5万用户，还有一万用户有PPOE是5千。还有常在线的我们直接按照1万算，然后拿IPTV业务，它现在30%渗透加并发，所以按照3千用户模型去打的。前提和背景都跟大家交代清楚了。
我们再来看这些数据，或者它对NFEI的要求的情况。目前来看在PPOE，IPTV和专线和综合业务里我们都是把网卡打满了，就是在这里放了两块8259网卡，四个万兆端口跑满的。这里明确一下，它测试的时候服务器直接连的测试仪，测试仪两边去测的。在这里实际上它的流量，如果按照硬件的设备去想的话就是有用户侧端口和接入侧端口，所以对NFE设备也是一样，就是有进和出的情况在ITM和VOP可以达到8万用户，CPU已经是它的瓶颈，网卡才用到8G左右的能力。我们做了一些性能的提升，就是顶层硬件设施的提升，其中包括芯片提升到两路14核的，主屏保持不变，是在2.4G，这里有V3到V4版本的提升。内存我们认为没有太大的价格差异，所以它其实不作为我们太多考核点。如果提升带来成本增加的话，就是我们的考核点。再一个就是网卡，网卡这块在性能提升的时候，或者在设施考虑的时候，我们在增强的环境里是用了X70网卡，每个网卡四万兆。我们会看到在中国运营商线网面向家庭用户业务里发放的四大类业务里，除了ITMS外，其他都跟网卡性能的要求是非常相关的，基本上都是网卡先达到瓶颈的。ITMS和VOP业务主要是CPU先达到的瓶颈，而网卡目前来看的话即使提升到X70网卡，也没有太大的并发的量的提升，其实还是有点，因为它在CPU和网卡抢占的时候，如果网卡通道更宽的话其实会有一些优化的，但是这个优化我觉得没有，从性价比来讲的话没有意义去突出更高能力的网卡。
所以在我们和省公司测试完成之后，就会得出一个结论，就是我在线网部署的时候，我要把一个宽带家庭用户的用户迁到AVA资源池应该怎么布，是不是还像以前的MSE或者BNG部署模式一样，上来之后全部堆到一台设备上去？其实我们发现经过这个测试会发现，不同的业务，包括包长不一样，其实对CPU消耗和网卡消耗完全相左的，我没有办法很好衡量出在综合接入层统一怎么布，所以大量的会分开布。我们看到通过引流引到资源池后，不同业务是有不从标识的，会转到不同的资源池。就是在资源池建IPTV控制面的资源池，以及POPE宽带业务上网的资源池，是这些建线网用户资源池接入到我们业务中来。
接下来讨论的问题，是现在的中国运营商非常关注的一个问题，就是业务的，NF1的形态控制和转发的分离，这个分离重要的原因，其实我觉得很多的标准组织致力于的事情大家是一样，我们为什么要把ONOS拿出来呢？我们再把一些功能通过XOS拿出来，其实是为了简化转发设备的功能。所以在转发和控制分离方面，我们希望控制面能够通过以资池的方式，以功能不断叠加，以虚机还是容器的方式都无所谓，我说的是表现出来的整体架构是一致的，就是它可以根据业务模型发展或者变化，根据业务需要扩展控制面或者扩展转发面，这样才会有转控分离的一些要求。以前我们汇聚机房和CO机房放的一台设备，全业务转发，所有业务都在这里来处理。这个是我们线网的常态，它有它的好处，就是网络特别简单，或者网络规划现在很定型了，就是我们非常熟悉。但是坏处也明显，就是升级业务功能很麻烦，以后再新增功能不知道该如何下手。所以在现在网络重构的架构里或者各个标准阻止在做的一些事情，我们认为是需要有一个前提的，就是转发和控制的分离，能够使得我们能够把这件事情更容易去做。这件事情来做的话，实际上同样在华三的方案我们会有一个边缘汇聚分流，就是业务从接入侧到DC内部，应该以怎么样的方式把不同的业务引流到不同的资源池当中去，这个还是存在。在现有的方案里，因为还是受限于现在宽带上网固有的现状，这个现状导致我们没有办法用一个 统一的，比如说便宜的硬件芯片的白盒做这件事情，可能还有一个过渡的阶段。实际上在过渡阶段会把容易，率先分流出来的放到NF1资源池里的业务首先把它拿出来。像IPOE大流量的视频业务，这占了很大的边缘扩容的成本，把这个拿出来。还有对IPOE大并发的也可以拿出来放在核心DC，和管理层布在一起，和后面的业务系统交互是资源集中化更有利，会有一个中间的阶段。在未来的阶段，在边缘DC内部，现在有很多的流派或者说有很多的争论，我个人还是认为它一定会有一个可编程硬件的芯片来主导市场。但是它的控制面实际上没有，上收拿出来放在核心或者边缘业务处理，这都没问题，但是是要把功能拿出来了。
这里还是我刚才所说的，在新的未来的架构里它会能够有更好的适应性的扩展，就是业务扩展的能力。比如要发展物联网的一些新的NFE网源出来，我可以很快的把整体的城域网架构进行统一，而不再是以前IP专业或者是宽带的专业，物联网专业是一个，它其实可以融合，真正成为一个MEC。
最后两个片子再介绍一点，就是在电信级云我们提到，电信级云和现在所看到的IT云，以及看到的政务云会有所不一样。以前的方案里可能是分散的去建我们的业务系统，当前的阶段实际上是将IT，就是运营商私有云，政务云或者加政企云以及电信云分三朵云来建设，这是目前的主流，大部分是这样做的。在新的方案或者未来演进趋势，我们认为云的趋势会是一个云架构，但是会有偏向功能的模块进行加载，它未来是一个统一的基础设施的存在。
我们提到的电信级云它和我们传统的IT现在用的私有云或者是政务云会有什么不一样呢？其实还是比较鲜明，尤其在可靠性，低时延以及性能上面它会做一个非常大的增强。这个增强我们有些数据的，这个事情其实跟联通研究院这边，还有包括跟电信的两大研究院，还有个移动的研究院我们都在做测试，华三也是在这块是主流的，我们希望一起来做的一个市场。
最后一个，因为我们做了很多线网试点和商用。这个商用回馈给我们的问题很明显，因为我作为解决方案提供商要比现在，包括开源组织，就是我们在使用过程中我可能有更多的问题需要去考虑，需要去面对，一个典型的事情，比如我们在某省实施我们Dbase R CORD，因为运维领导是做IT出身，你以前的硬件设备要支持哪些，跟我的网管接口的对接和告警系统的对接，都接上来，让我全部看到。没问题。但是作为厂家提供解决方案来说会有些差异，为什么呢？以前更多在SNP上面做的，不断分布密布结。但是现在会转一些东西过来，所以研发的精力会分散，我今天想说这件事情，我们对待重构是需要用发展的眼光来看待这个问题，来这个解决方案。我确实很想讲这句话，不知道合不合适。为什么呢？因为我按照你的要求，看原来设备提供什么功能，还能对接什么，这个没错儿，但是现在构建在IT设施之上的网源，其实本身维护的东西的界面就已经超过了。有一种方案是运营商的运维团队本身去做整合，但是现在在试商用阶段很难。第二，我们在提供解决方案的时候，我们会考虑你IT资源的监控，故障的告警，上送等等这些事情，如何跟我的CT网源告警等等东西联动起来，最后帮你做对接。这个才是合理，快速加载线网商用的方法。我想说的就是这个，我们以前更多考虑的商用版本的更多考虑的是业务开通。接下来做的事情，其实我们在线网部署的时候，由于试商用这么多用户传载上来了，我更关注的是运维，有问题工程师能快速定位是CPU哪个核出了问题，还是什么地方出了问题，这是需要跟现有工程师磨合的方向。刚才黄秉钧讲的很好，会有不同组件监控，未来可能还会有一个帽子，把这些东西做一个统一的呈现，我深有感触，因为我们在线网业务部署的时候就遇到了这样的问题，首先要Underlay然后Openlay。这在未来的运维中会有问题的。所以这里我们从解决方案角度，会想如何把这两件事情进行拉通。拉通其实有好几个层面，包括部署，先要部署Underlay，然后再部署Openlay。第二，出现故障的时候怎么定位，还有需要跟告警系统对接，甚至告警系统也需要做升级来适应未来的变化。我想表达的就是在重构过程中遇到各种各样的问题，和以前重来没有遇到过的问题。没有关系，每件事情只要有问题，就一定有解决的办法。所以无论开源组织做的一些努力，还是说我们这些解决方案提供商或者设备提供商也好，我们来做的事情，其实是大家一起在重构的过程中我们去找到一些解决方法的。这个就是我今天想要给大家汇报的，谢谢。
