分享嘉宾：马绍文，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、介绍
在1990年代Yakov, Eric Rosen, Kompella很多业界先驱(仅列举了Juniper公司的MPLS业界领袖，其他公司也有 很多Fellow推动MPLS发展)的引入MPLS之后，作为一个业务传送协议，MPLS取得了极大的成功。MPLS发展出很多不同的协议，简单的LDP/RSVP-TE，组播等,承载各种VPN业务，结合各种OAM功能，甚至扩展到光传输领域。
为什么我们需要一个新的IETF协议来指挥MPLS转发呢? 下面会介绍一下这个名叫『春天』的IETF工作组。Source Packet Routing in Networking 简称为SPRING，也有叫做Segment Routing(段式路由)，我们下文一般称为SR。
在介绍SR之前，我们先来看一下SDN2.0.
2008年左右提出的Openflow促进了第一代SDN的热潮，大家都想用Openflow(ACL)去控制网络中的应用流量。Openflow在数据中心领域取得了一定的成功。 扩展到广域网和运营商网络时有了一些Hyberid SDN的部署，也遇到了重重的困难。
其中一个重要问题是Openflow对网络抽象不够，网络核心设备中网络状态信息随着应用数目的成指数增长。无法在广域网中得到大规模的部署。并且Openflow控制的网络，往往需要控制器控制路径中的多个关键设备，网络中的Touch Point增多，导致运维困难，信令压力增大。
采用SR来作为传输协议的时候，SDN控制器仅仅需要跟Ingress PE通讯，在Source路由器上已经通过携带多个标签，定义好了完整的路径信息。网络中的Touch Point仅有一个，就能影响到这个应用APP流量的转发。同时网络核心设备中网络状态信息完全跟承载的应用业务无关。采用SR
的运营商可以轻松的为百万级别的应用在头端(source)路由器选用不同的路径，同时保持核心设备没有任何应用状态。(Edge Intelligence, Stateless Core)。
2、SR协议介绍
SR的基本概念类似Lego，把网络分为不同的段(Segment)，然后拼接起来。首先把网络分为三中基本组件。
邻接段(Adj-SID)，连接另一个路由器邻居，local有效。
节点段(Node SID)，指示如何到达另一个本地/远端(local/Remote) 路由器
网段(Prefix SID)，指示如何到达一个IP prefix.
在头节点(Ingress Router)就用这不同的组件来组织一个完整的LSP Path。为了避免各个厂家设备采用不同的标签块，SR借鉴了传统的K.Kompella提出的BGP VPLS的基本概念。每个路由器宣告一个SRGB(SR Global Block全局块)，在同一个区域(Domain AS/Area)中的每个路由器有个唯一的Index。
以ISIS扩展的SR为例，每个路由器都可能会宣告这三种基本的SID(还有一些其他类型的SID，比如Anycast SID等)。
每个路由器会计算SPF路径树，来构建节点段(Node SID)的一个完整路由器互联的拓扑(跟传统ISIS一样)。
SR路由器继承了MPLS的转发平面，仅仅是优化了控制平面。采用IGP/BGP来分发标签，取消了之前的LDP/RSVP-TE。
第一步，建立拓扑:下面介绍SR网络关键的第一步，如何建立转发表和拓扑关系。
在一个支持SR的路由器里面，MPLS转发表会包含Node SID，Adj-SID 等(Prefix SID没有在图中显示)
Node SID表：如果路由器都采用相同的SRGB，对于任何一个远端路由器在转发表中会有一个独特的In/Out label 完全相同，也就是说Label SWAP操作之后还是相同的标签。每个标签代表唯一的一个节点。如果是相邻节点的Node，会有POP操作。
Adj SID表: 这个转发表也只有POP操作，所有收到的Adj label最后都被POP出来。
总结一下，SR的转发表，如果是相邻的Node/Adj会被POP弹出标签栈。所有的Node/Adj/Anycast/Prefix SID 都是IGP扩展来宣告给其他的路由器。每个路由器收到Node SID进行SPF计算，计算出一个树型MPLS转发表(跟正常OSPF/ISIS计算出来的拓扑一样)，路由器收到Adj SID信息直接产生Adj POP操作。
第二步在基础IGP转发拓扑之上，控制器或者VPN等应用会来构建一个LSP Path，还记得前面提到，路由器收到Adj SID/相邻的Node SID label会POP出来，移掉最外层的标签。在图中的例子里面，如果在Node 11上加上4个 Adj Node SID，在1/7/4/14节点都会移除最外层的标签。最后把Payload发送到Node14节点上。同样你也可以在头端路由器压上Adj SID标签，这样每个接口转发之后移除一个标签。
上述过程可以想象为一个行李标签，比如我定了个机票：新加坡到洛杉矶，我买了个复杂的机票：11(新加坡)-1(香港)-7(北京)-4(旧金山)-14(洛杉矶)在新加坡时候我checkin行李，会拿到香港-北京-旧金山-洛杉矶行李Tag，行李托运之后，在中转的每个城市取下一个行李Tag，最后行李安全到达洛杉矶。在每个城市，仅仅根据最外层的Tag转发到下个城市。在头结点(source)行李的路径已经确定。
当然SR可以压多个标签栈，也可以类似RSVP-TE/LDP似的仅仅采用一个标签也可以Follow IGP达到终点。比如右边的图，可以采用标签114顺利到达节点14，中间的每个路由器都收到label114，然后转发出label114，继续下个节点，直到节点14pop。
上图可以看出来，SR转发可以采用不同的混合机制，灵活的采用标签栈来指导每一跳的转发，也可以根据IGP路径采用一个标签来跨越一个很大的网络。也可以添加各种流量工程的策略，来进行ECMP转发或者避免哪些SRLG来转发。
2.1 采用Anycast进行节点保护
接下来介绍一个非常好用的功能，Anycast节点保护。
传统的MC-LAG和Virtual Chassis功能作为节电保护，总是存在各种问题，多厂家无法互通，两个设备同样版本，设备间交换私有信息无法进行ISSU，无法多个设备备份，上下行流量保护问题等等。
SR推出了一个全新的功能Anycast SID能有效的解决这个问题。你可以选用一组设备2+，每个路由器在发布正常的Node SID的同时，还发布相同的Anycast SID。这样在R1节点收到5100的标签时，R1就会发送给4个路由器中的任意一个(outlabel 8100)。假设A1收到8100，会Pop出来8100，A3看到8070。A3就转发给R2(keep8070)。R2收到8070之后会POP，剩下Payload转发。假设A1节点失效，R1会发送给A2/A3然后发送8070到R2。
Anycast SID适用于任何拓扑，环形/Hub&Spoke etc.也适用于ABR/ASBR保护,同时适用于Seamless MPLS(后续会继续讲解)。
2.2 100% TI-LFA节点/Link保护
SR的另一大优点是可以提供针对任何拓扑100%的FRR保护。
大家知道LFA和Remote LFA都只能覆盖80-90%的拓扑，针对复杂的环形网络无法提供100%的拓扑情景的支持。
针对这种场景，Juniper最早提出了TI-FRR的解决方案。采用Target LDP和RSVP-TE结合的方式，可以做到100%拓扑的50ms快速重路由。
解决的思路是计算PQ节点集合。P节点集合：从E1出发，可以达到的节点集合，不需要经过中断路径。比如{E2,E3}是P节点集合。从E1出发到E4就可能经过中断路径。
Q节点集合：到达C1的节点中，不需要经过终端路径的节点，以C1为根计算的反向生成树，{E4，C2}是Q节点集合。
如果采用普通的R-LFA，PQ集合没有交集，也就是说R-LFA就不能保护这个拓扑。采用TI-FRR需要直接在E1到Q节点创建一个RSVP-TE Tunnel，这样被保护的流量就没有microloop回来，到达E4之后采用Target LDP session来确保流量流向C1。从而TI-LFA可以做到100%的拓扑保护。
采用SR的保护机制不太一样，在disjoint PQ集合里面，首先利用Node SID选择P(E3)节点，然后压上Adj标签(E3-E4)，也就是告诉流量首先发送到E3，正常情况下有可能会回流到E1-C1链路。这时候SR要求流量到了E3之后，继续转发给E4。也就是两个label，两个动作确保了100% FRR.
2.3 利用Binding SID扩展网络规模
采用SR的一个很重要的顾虑是硬件能压几个标签?比如B厂商的商业芯片一次只能压三个标签，可能通过recircle来压多个标签但是会带来性能的损耗，同时带来其他问题。
为了让SR可以在各种场合适用(比如运营商汇聚)，SR开发了Binding SID。 通过IGP/BGP来发布一条SR-LSP(从R22到R30，标签栈为{332|331|330})的标签，假设这条SR-LSP的标签为510.在R21处只需压入两个标签{22|510},当R22收到22时pop标签22，露出来510，R22会把510去掉，同时压入3个标签{332|331|330}，这样报文最后会抵达R30。
通过Binding SID也可以实现RSVP-TE/LDP和SR的互通。还有LDP mapping Server等具体的办法就不详细介绍了。
2.4 基于PCEP/BGP-LS的SDN控制器
最早利用SR来支持SDN的想法来自于PCEP/RSVP-TE类似的做法。在控制器端计算完整的流量工程路径，然后把路径列表通过PCE带给路由器上的Client端(类似RSVP-TE ERO)。非常类似RSVP-TE，好处也明显，不需要沿途的路由器发任何信令去建立LSP(RSVP需要发送 Path/Reserve message)。
首先介绍一下SDN控制器来使用PCEP建立SR-TE tunnel。
非常类似RSVP-TE的PCEP LSP建立过程。控制器的PCEP会通知路由器上的PCC来协调能力，同时采用类似SR-ERO的方式来携带Label Stack，PE收到PCCreate LSP消息之后，不需要像RSVP-TE那样在多个路由器之间传递PATH/Reserve信令消息，仅仅需要下发label 堆栈信息。同时LSP创建的状态汇报通过SR-RRO来传递回去控制器。
采用BGP-LS来传递TEDB，并携带SR label信息送回控制器。
对于VPN业务的映射，可以采用PE-CE之间的Openflow/PBR/QPPB/BGP Flowspec 等。
可以参考Juniper的SDN控制器North Star可以动态的建立SR TE-LSP，并且观测每个链路, LSP的标签信息。同时根据流量分布，可以动态优化SR LSP。
2.5 SR和传统LDP/RSVP-TE的对比
简单的对比一下SR和LDP/RSVP-TE。
首先网络中间节点只需保留很少的网络状态，SR甚至不需要理解网络中的远端状态信息。比如节点3，不需要任何关于link 11-1, 6-7的Non-adj转发信息(而这些信息在LDP里面是存在的)。SR的基础转发表甚至比LDP更简洁。当然比RSVP-TE状态少很多。同时不需要LDP/RSVP信令来建立LSP， ingress node上出现不同的Label Stack组合，马上代表不同的路径选择。
这张图比较了传统MPLS(RSVP-TE/LDP)和SR的多种情况，控制协议，流量工程，FRR，inter-AS/Area，扩展性， OAM，和SDN集成角度，SR有一定的优势。
3、SDN的应用场景
介绍SR的各种SDN应用场景之前，我先来介绍一下云计算如何来无缝对接SR，实现云网合一。
先看传统的Underlay网络，由路由器，交换机，防火墙等组成，连接方式很固定，一旦配置了之后大概半年/一年都不会进行更改。 采用Ansible/Puppet进行配置管理之后，可能需要进行一系列的检测和排错。总之网络比较稳定，运维简单。
但是新的云运营模式，需要全网转去DevOps模式才能适应云计算。
DevOps能帮助客户在物理网络之上创建一个虚拟化的网络。APP/Dockers/VM能够更快的部署在全球网络上，并采用Scale Out的方式实现海量客户的接入，更灵活的做网络的变更。Overlay网络管理的不再是物理的设备，需要管理海量的虚拟路由器(vRouter)，OVS，VNF (LB/FW/DPI)等。怎么去维护管理这个虚拟化的网络，需要一个SDN控制器帮忙。
越来越多的客户采用SDN控制器来进行DC内部Service Chaining和跨DCI的选路。
如果在underlay网络中部署SR，云服务就可以通过BGP-LU/PCEP/Netconf等协议来对Source节点进行编程，可以选择DC里面的Leaf/Spine路径，也可以选择DCI的SR-TE LSP来进行跨DCI的流量工程调度。
SR标签可以包含：{APP|Docker|VM|Server }映射关系，还可以包含NFV label进行Service Chaining，还可以包含VPN Label，进行VPN隔离，同时还可以包含Label Stack穿越广域网。采用不同的label组合，在增加任何影响underlay核心路由器转发表的情况下，可以支持百万级别的应用。
关于SR的应用场景，我们看到越来越多的客户选择四个不同的场景来部署SR，比如
数据中心，拓扑比较简单，EBGP来作为IGP协议，同时采用同一厂商的设备，统一的SRGB来管理大规模数据中心。
广域网在核心/边缘路由器上部署SR， FRR特性，同时减少Core Router的状态，采用BGP-LS来上送Controller网络的标签状态。采用BGP-LU，FlowSpec来控制流量 承载在不同的SR LSP。
城域网在汇聚路由器，移动回传的网络中，采用环形网络，利用SR的100%拓扑，采用Binding SID来跨越多个Area/AS，并且采用PW来进行业务的承载，简化Cell Site设备协议，取代传统的Seamless MPLS。
下面详细介绍一下各个Use Cases：
3.1 SR在超大规模数据中心的应用
在介绍数据中心应用场景之前，先介绍一种新型的BGP控制器来建立SR-TE LSP的解决方案。
BGP-LU(RFC3107)在业界有多年成功部署应用，大部分厂商设备都支持BGP-LU，包括Metro里面的很多小型Cell Site路由器。
传统的BGP-LU仅仅能够携带一个标签，Juniper的设备扩展了RFC3107，可以在控制器和设备之间传递多个标签栈。
这里我们采用了非常简化的ExaBGP(Github免费BGP，https://github.com/Exa-Networks/exabgp)安装在笔记本电脑上，并且跟路由器建立简单的BGP-LU session。ExaBGP Controller来发送一个BGP 消息给PE1，这个BGP-LU消息携带四个标签栈。可以指导PE1创建不同的SR LSP转发表项。
同时如果采用QPPB/BGP FlowSpec 来映射PE-CE之间的流量到BGP-LU创建的SR LSP上，就只需一个BGP协议，SDN控制器和路由器就能协商业务流的控制。
现代大规模数据中心设计，Underlay刚刚经历了VLAN到VXLAN的演进，很多客户会问，为什么要在DC引入MPLS，为什么要引入SR?引入SR的几个主要的优点如下：
1.越来越多的Overlay采用MPLS，比如Contrail采用MPLSoGRE，MPLSoUDP， EVPN+MPLS等协议。在广域网和DC采用相同的MPLS协议，带来的运维好处显而易见。比如DC GW不需要在VXLAN和MPLS之间进行协议转换(避免性能可能下降)
2.同时由于Telco Cloud，越来越多的NFV采用MPLS VPN协议隔离。
3.可以更好的指导Elephant Flow转发，避免ECMP Hash时候Elephant Flow和Mice Flow竞争同样的资源。
4.可以更好的进行故障隔离，传统TCP Flowlet把网络变为黑盒，拥塞之后就会调低传送速率。如果能够理解网络中拥塞，不需要降低传送速率，仅仅需要重路由到非拥塞链路，会极大的提高App的传送质量。
经典的超大规模DC设计，取消IGP(避免网络链路震荡，路由重算)构建基于BGP 的数据中心。请参考Juniper 白皮书, EVPN IP CLOS for Next Gen DC
在超大规模数据中心里引入SR，是一个比较热门的话题。draft-ietf-spring-segment-routing-msdc在持续讨。草案里面定义的是基础Leaf/Spine架构如何用BGP-LU+SR来构建。我们这里来介绍一下端到端的VM/Docker是如何通讯的。
Leaf 跟控制器建立BGP-LU(3107)session，传递vRouter Prefix SID的标签信息
Leaf/Spine建立BGP-LU session，传递Leaf labels， Spine不需要跟控制器建立session。
控制器创建VM/Dockers时，在vRouter上给分配标签，通过BGP/XMPP上送到控制器
在Ingress vRouter上压入三层标签栈，就可以找到egress (TOR，vRouter, VM)
有了这套完整的SDN 控制器体系，配合广域网SDN控制器，可以很扩展到DC互联。在DC互联中，可以采用的技术有如下：
SR可以很容易的利用Node SID来实现ECMP，可以利用Adj SID去精确指导选用哪条Link。
可以利用SR的Anycast SID去保护DC GW和广域网路由器
在图中例子可见在Ingress vRouter标签栈依次为：{ DC1 | DCI A-B-C | DC2 | DC2 vRouter | DC2 VM}, 需要说明的是，即便可能压入8-10+个标签，报文头还是比VXLAN(60-70 bytes)小。
3.2 基于SR 的Cloud Peering应用
传统的流量工程仅仅 关注在IGP域部分，越来越多的企业迁移到云服务。如何找到没有拥塞的BGP Peering提高网络云接入能力?基于SR的BGP EPE能提供一个更好的解决方案。
ASBR通过BGP-LU(3107)跟控制器建立BGP邻居，并且给每个Peer分配一个标签。
ASBR通过BGP-LS, Netflow, Telemtry把流量信息上送到控制器。
控制器计算最优路径(latency/bandwidth/optical SRLG etc)
控制器在头结点压上多个标签，外层SR标签找到ASBR，内层BGP-LU标签找到Peering,外层隧道也可以采用GRE/LDP等。
在BGP EPE转发路径上有个比较特殊的属性，从AS内部到peer的转发，不需要查询路由表，仅仅需要MPLS转发。利用这个特性可以采用新型态的LSR /Lean Core设备做Internet Peering。
完整的看一下数据中心和WAN的统一控制器，可以控制从数据中心服务器发出的流量，选择不同的ASBR，不同的BGP Peering，从而避免拥塞。 从Internet进入到数据中心的流量，控制器可以监测VM/Dockers的运行状态，从而在ASBR开始压上不同的VM标签，数据流量可以根据VM/Docker分发的不同标签来进行负载均衡。
3.3 基于SR 的下一代接入网
对于运营商来讲如何降低接入网的成本，是一个首要问题。对于采用SR的cell site 路由器，可以实现最小的协议支持，同时承载各种VPN业务。网络的传输部分简化为ISIS协议，网络的业务部分采用BGP承载VPN，甚至采用BGP FlowSpec来映射客户流量。减少Cell Site Router的协议复杂度，就会增加网络可靠性，可维护性。
主流厂商多年前就已经支持Seamless MPLS(UMMT)的Mobile Backhaul解决方案。方案采用RSVP-TE做接入环网的保护，BGP-LU为多个区域粘接在一起，提供端到端的LSP隧道。加上VPN标签，和FRR标签，需要4个标签(经常导致B厂商的商业芯片无法只支持三个标签)。
如果采用SR，可以利用协议简化机制，利用100% FRR保护，利用Anycast SID保护汇聚节点，利用Binding SID在汇聚设备扩展SR LSP跳数。
SDN最早起始于数据中心，就是因为要管理很多TOR和Server。很多客户有上千台Cell Site路由器的规模，引入SDN控制器，并且采用ZTP自动部署SR。越来越被主流运营商接受，成为运营商采用SR的一大驱动力。
3.4 基于SR的Telco Cloud
传统运营商建网思路是以连接性为目的，买路由器，传输设备，提供管道，连通性。网络架构基本不具备智能。
随着5G，虚拟现实，IOT，HealthCare等业务越来越多的业务承载在运营商的网络上。低延时，大带宽，大规模业务，需要运营商建设更多的Micro Data Center，更加靠近客户和应用。驱动运营商的网络从传统的连通(PIPE)导向的建设思路，转型到建设运营商云服务平台(Telco Cloud) 上来。
为了应对新业务的出现，很多业界运营商转变思路借鉴了许多OTT的建网思路实现以超小(Micro)，Ultra Low Latency数据中心为网络建设的重点。比如为应对VR/Health Care/自动驾驶等业务的低延时，大数据量应用(自动驾驶汽车需要视频识别，可能每秒钟产生1Gbps的流量)，必须要建设全分布式，超小型数据中心更加靠近终端用户 。
把数据中心DC Fabric网络架构应用到城域网，建设很多SP Fabric,通过SR无缝连接起来称为Telco Cloud架构的基础。
典型的Telco Cloud在SP汇聚层会采用BGP-SR添加很多小型数据中心。在SP数据中心中Leaf节点有不同的工作职责：
A-Leaf用来接入用户，比如ONU，Wifi，BNG客户等
C-Leaf用来接服务器，用来虚拟化vEPC，vFW，vDPI, vOLT, vBNG 等
P-Leaf用长距光模块做互联。
采用BGP-SR在SP Fabric，Metro利用OSPF SR，提供端到端的SR LSP，业务采用EVPN承载。
3.5 基于SR的网络虚拟化NFV Service Chaining
网络虚拟化也是运营商最热门的话题。网络分块(Network Slicing)和业务链(Service Chaining)也越来越重要。Service chaining表现出新的趋势：
不光局限于骨干网DC，往往分布在Front Haul的Micro DC(小微)，在城域网BNG附近的中型 DC，和国家骨干网DC分别处理不同的虚拟化业务。
Service Chaining可能无法在一个数据中心处理完毕，需要在城域范围内跨越多个DC。
业界有厂商引入特定的NSH(network service header)头来支持业务链，但是采用专用报文头可能会带来两个问题，很多VNF(比如vFW, vEPC etc)不支持NSH，大部分硬件交换机无法支持NSH。
由于SR可以指定访问网络中的任何节点(通过多层标签栈)，同时大部分的虚拟设备和物理设备都可以支持MPLS转发平面，所以很多客户想要采用SR来支持Service Chaining。
4、总结
前面介绍了很多SR的应用场景,作为一个underlay技术，SR可以广泛应用在网络的CPE/Access/Edge/Core/DC里，同时更好的支持SDN/NFV.
最早美国的很多Web/OTT公司Google, Microsoft非常感兴趣SR。还有一些欧洲美国的TOP SP，ATT/Comcast等，最近在亚太区，中国的OTT，日本Softbank/NTT/KDDI,加上澳洲的Telstra都很感兴趣，SR在2017会有更多的客户采用，部署。
最后，分享一下最近的SDN/NFV感想。
最早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自愈合控制系统。
前面讲到的各种SR的网络优点，可以看出来采用了SR的智能边缘，无状态核心设备的网络基础架构，不但理解Underlay网络架构，同时理解Overlay云端应用，促进云网融合，会成为今后SDN/NFV发展的坚实基础。
Juniper的网络远景是打造『自驱动的网络架构』-“Self-Driving Network”
Q&A
Q1：使用MPLS/SR，相比VXLAN，如何能避免ECMP Hash时候Elephant Flow和Mice Flow竞争同样的资源呢?
A1：如果采用SR，可以给Leaf/Spine里面的16路/32路 ECMP，每条link分配一个不同的Adj SID，同时监测不同ECMP link的链路利用率，这样就可以避免资源竞争。比如Google要求在网络中的telemtry流量统计，最小可能10ms这种级别。这样控制器在收到大量的信息之后，通过机器学习算法，动态调整/预测网络的拥塞情况，从而避免。最小10ms,正常100+ms级别，这样还有机会影响流量
Q2：这样做是否与flowlet不兼容，两者只能选其一?
A：是的，可以在server端用flowlet做优化，也可以在控制器层面，下发不同的Adj SID在交换机层面，来做负载分担
Q3：anycast那部分我也没有太看明白，例子里anycast sid是 100，为什么出标签8100?
A：Anycast的ID是100，但是他们的SRGB，(SR 全局块)起始标签是8000，所以标签是8000+100.
Q4：我没太听明白您说的SDN和segment routing的关系，您是把segment routing当做一种underlay技术，用来实现SDN呢，还是说在SDN上实现segment routing有先天的优势?
A：两个层面的SDN，如果说网络的SDN，segment routing可以帮助选路，也就是我们Juniper的North Star,做流量工程，Cloud Peering等等。 如果说Cloud SDN，比如juniper的contrail，SR可以灵活的实现VM/Docker的通讯(通过contrail vrouter)。当利用Cloud SDN的时候，可以通过segment 的基础架构，更容易的连接Cloud里面的APP
现在Telco Cloud, NFV里面采用了很多的label来做VPN隔离，VNF隔离等。这时候采用SR会有一定优势
Q5：DC + DCI 的客户案例(pilot ok) 有了吗? 是OTT and 运营商?
A：DC+DCI的应用场景，一般是运营商SPDC和OTT。跟Microsoft SWAN和Google B4，差不多，都是一个控制器，端到端来控制VM，控制ASBR，只不过SWAN准备用SR做，B4现在用GRE做，今后转向SR。
Q6：在J看来，BGP-LU和SR是竞争关系吗?两套控制面吧，一个是BGP一个是IGP
A：SR的信令协议，可以采用IGP(OSPF/ISIS)或者BGP，BGP还有个新的draft BGP SR-TE也会比较popular。BGP-LU是juniper用的多，SR的一些基本概念可以用BGP-LU来实现。
Q7：关于三个SID我还有些小疑问哈，Node SID 和 Adj-SID 二者是什么关系呢，都是由控制器来分配的吗，是不是说相隔多跳的两个路由器有可能分配相同的Adj-SID呢?Prefix SID是什么作用，如何工作呢?这三者是网络中的每一跳都会具有的吗?
A：Node SID是loopback一个路由器一个，Adj SID是相邻的接口(Adj)，假设路由器有4个物理接口，其中有3个有SR的邻居，那么Adj SID就有3个。相隔多跳的路由器很可能有相同的Adj-SID，比如大家都共享一样的SRGB，第三个接口的Adj-SID就是一样，但是也没有关系，因为Adj-SID是local有效的。Prefix-SID不是必须的，比如客户仅仅是做traffic engineering，所有的traffic都是VPN traffic，这样就不需要prefix SID，只有IP traffic over在SR上的时候需要prefix SID。还有客户实现只有Node，或者只用Adj的网络。
Q8：比epvn控制平面的vxlan有哪些好处呢?
A：对比EVPN+VXLAN，采用SR的好处，1. VXLAN报文开销太大，我前面提到压7-8(30+bytes)个标签之后，报文头还是比VXLAN小(68 bytes). 2. WAN/DC 都采用相同的MPLS转发平面，3.不需要在DC GW那里做VXLAN到SR的转换。4. Telco Cloud里面的vRouter比如contrail天生携带MPLS 标签，VNF也是靠label来区分的，也就是说在Telco Cloud里面，即便用EVPN+VXLAN，最后也有MPLS Label，Telco Cloud更prefer用EVPN+SR。
Q9：这个你跑通了吗。 去年我试过，没有成功。
A：没问题，跑通了，我们有个白皮书，公开资料，回头可以发给大家，如果用BGP-LU来控制SR的不同路径
Q10：想问下Prefix SID是什么作用，如何工作呢?
A：Adj SID是个标签，prefix SID，这里没有太多介绍，可以想象为ASBR，使用BGP prefix SID，这样为这个SID分标签的时候，就要找到ASBR，同时压上prefix SID的标签，前面提到，IPoSR的时候需要prefix SID，如果是VPN traffic，只要Node或者Adj就足够了，还有客户实现只有Node，或者只用Adj的网络。
Q11：exabgp的性能是个问题啊。只能做demo
A：可以用vMX，最近出了个route server版本，全面开放编程接口JET，全路由，SR/MPLS编程接口
Q12：能介绍一下Telemetry方面的标准，协议和关心的具体NFVI和VNF的哪些参数嘛?
A：关于Telemetry，回头可以找个时间好好介绍一下，再介绍/Demo一下juniper的一个非常好用的开源工具Open NTI https://github.com/Juniper/open-nti
Q13：在SR的实现上，CONTINUE动作被映射为MPLS 的SWAP，Next动作被映射为Pop，那么是不是说SR里的每个segment都需要被定义为一条LSP呢?
A：Segment只是lego的基础，本身不会很多，多少个邻接，多少个node就有多少个segment，比如prefix segment数量可能很多。每个LSP可能包含多个segments，LSP的数量可能多余segments
Q14：NSH传统SFC方法，要求SFC支持NSH头，但是像SR这种头是可变长的，例如一个firewall vfunction，一定要parse完才知道到栈底，从这点来看，我觉得他对SFC的支持并不是那么好，请问你的看法是什么?
A：SFC支持NSH，除了Edge设备，或者vrouter，很难支持，采用SR来做，可能中间处理vFW的时候，还有多个标签(后续的VNF处理)但是找到栈底的处理不难
Q15：vMX 怎么发 SR 的LSP啊?我记得onos有SR for DC 的项目
A：这个是VM可以通过JET开创建多个label的SR LSP，我们给中国一个著名的OTT做了个Demo，本来我要介绍的，因为时间关系就取消了。 ONOS的那个项目是2014年的，拿Dell的交换机，用Openflow创建了个Segment Routing的网络，很古怪的想法，demo在youtube上可以找到，当时还比较原始，Openflow还只能最多压3个标签，ONOS做了个recircle可以压多个，但是性能很差
Q16：openflow + SR..... 我的理解 Telstra 的 SDNWAN 项目也在用 open flow + SR.... 感兴趣open flow在这场景下的具体怎么与SR分工协作的，这方面有insights吗?
A：我知道的Telstra SDWAN，很快会上线25个客户。采用跟ATT一样的CPE设备，采用netconf来配置，上行接口还是MPLS，只是考虑SR，还没有开始商用呢
Q17：recircle指什么?芯片吗?还是流表的recircle?
A：对，Openflow一个action可以压3个，如果需要压多个，就把多个ACL串接起来，就是ACL的最后一个action还去应一个ACL，这样就可以压多个，同一个报文要过多遍的芯片流水线
Q18：请教一下目前Juniper的路由器标签能支持多少个
A：硬件可以支持很多，比如MX，一个DE说最多可以支持压30+标签，PTX至少8+个，标签栈的深度不是问题，比如在DC里面，和Core里面转发都很简单，不会看到那么多标签。vRouter和MX的位置，处在网络的边缘，需要压多个标签
Q19：open NTI 支持其他厂商的设备吗?
A：我们全力支持兄弟厂家，包括大河
Q20：SR的底层支持来自于MPLS，segment routing的continue动作被映射为MPLS的Swap操作，next动作被映射为MPLS的Pop操作。那么是否相当于网络中的每个prefix-ID，adj-ID和anycast-ID都需要被定义为一条LSP。
如果是这样的话，相比于传统的MPLS，采用segment routing的方法，LSP的数量和转发标签的数量会不会变得更多，增加网络的复杂性和管理开销。
A：其实有一张图说的比较清楚，采用SR之后，路由器的转发表比LDP还小。
因为是文字分享，没有办法详细解释，你看这张图，比如LDP会保存远端Adj的转发信息，而SR仅仅保留相邻的信息。在SR里面路由器3，不关心link 11-1，link11-6等信息，在LDP里面都有。
其实SR解决的是Core核心设备无LSP状态，边缘的设备，可以有很多SR-LSP的标签，如果你支持很多APP，每个APP走的路径都不同，当然有很多状态，但是介绍中也说了，一般Edge的LSP可以用SDN控制器来管理。
在头结点，一个IP prefix查表的结果是一个压上一个label stack，你可以把它叫做转发表项里面的LSP，在控制平面，你有一个PCC客户端收到(PCEP配置的SR LSP)在控制器里也有。。你说他是LSP么?可以叫做SR LSP
Q21：SR简化了core的配置之后,如果出现了故障, 传统的troushooting方式可能无效了, 是不是说在application里也要集成一些用来排错的工具?
A：非常好的问题，比如采用PCEP的SR和采用PCEP的RSVP相比确实省去了中间Core的状态，但是SR无法track每条LSP的状态(是否真实走到要求的路径)，也无法通过PCEP把流量状态带回控制器，确实需要一些APP层面的监控，还有端到端的OAM，比如seamless BFD等等
Q22：请教一个问题，vxlan+evpn可以一个vpn同时是l2,l3转发。sr是也能实现这个功能吗?
A：没有问题，SR+EVPN也可以实现EVPN的Type 2+Type5，L2/L3 IRB同时转发
