Marketing Presentation Speaker Name Designation Date: 00/00/0000 Marketing Presentation Speaker Name Designation Date: 00/00/0000 Evolving the SP Network Infrastructure Dennis Cai Distinguished Engineer, SP Infrastructure Team 05/2015

Agenda Evolving the SP Network Infrastructure The Technology Innovations ‒ Segment Routing ‒ x-EVPN The Architecture Evolution: ACE (Agile Carrier Ethernet)

Storage Network Evolved Programmable Network Compute Evolved Service Platform Applications / OSS/BSS Device Model Service Model Cisco Open Network Architecture Vision

Data Center SDN (APIC, VTS) Data Center SDN (APIC, VTS) Metro access Control (WAE, ODL) Metro access Control (WAE, ODL) Metro and Access WAN Data Centre Domain / functional APIs CPE Multi-layer WAN SDN (WAE, ODL) Multi-layer WAN SDN (WAE, ODL) Cross Domain Orchestration (Tail-f NSO) Transport Optical Cisco’s Unified SDN Architecture for SP Network Infrastructure CPE EPN ESP

Future Operational Complexity Vendor Specific OS Integrated HW and SW Now Smooth Transition to the Future Network Infrastructure Inter-operable Back-compatible Multi-services Service SLA ? Operation, Visibility Service Agility: Fully Programmable Optimized and Application-aware Routing PnP of the BW capacity Network Infrastructure as Platform Device-Centric Investment protection

Let’s start with SDN… driven by different business interest CP/DP separation NFV white box openflow Open stack Controllers ODL … Programmable

What Our Customers Care? Services, Application Device-centric  Network as Platform OPEN API Low OPEX and CAPEX Service agility Business outcome … Routers Switches R R S S Individual boxes, Cisco, Juniper, XR, XE, J, A, H … FB Controller Box is PnP, with limited local function

From Device Centric to Network-as-Platform Data Plane Control Plane Config Plane Device centric view Orchestration SDN Controller Network-wide view Network-wide orchestration replaces the individual device config. This allows network wide service definition and deployment The SDN controller behaves like a centralized control plane for network wide policy & control. Examples of network wide policies include application-aware routing, multi- layer traffic optimization, bandwidth calendaring & scheduling. What need on the device? Packet forwarding Efficient route distribution Rapid convergence with local failure detection and repair Local features: L1 features, OAM/PM, QoS, Timing, mcast replication …

It will be a long journey … Orchestration SDN Controller Orchestration SDN Controller Centralized service provisioning Work with existing network devices Reduced Control Plane on Device AN: Autonomic Networking SR: Segment Routing X-EVPN Network as Platform Fully programmable Device is PnP component With minimal local intelligence on device Tail-f NSO WAE Tail-f NSO XRv+ODL WAE Next Future Phase Now Full control plane on device Reduced control plane on device Minimal control plane on device

Agenda Evolving the SP Network Infrastructure The Technology Innovations ‒ Segment Routing ‒ x-EVPN The Architecture Evolution: ACE (Agile Carrier Ethernet)

Introduce Segment Routing (1) Segment Routing is a Source Routing The source chooses a path and encodes it in the packet header as an ordered list of segments (Segment could be MPLS label or IPv6 address) The rest of the network executes the encoded instructions without any further per-flow state The intelligence is on the source router, while the rest of the routers can be kept very simple Source router intelligence is programmed by the external controller Application-engineered routing Seamless integration between network and controllers Simplify the MPLS and Routing

Introduce Segment Routing (2) Is there middle ground? DistributedCentralized Right Balance It’s right balance between distributed routing intelligence on the router and the centralized intelligence on the controller Router keep minimal local intelligence for features such as fast local re- route, shortest path forwarding within the local routing domain Complex inter-domain routing and application-aware routing are moved to controller to keep router as simple as possible

Data 7 7 Dynamic path Explicit path Paths options Dynamic (STP computation) Explicit (expressed in the packet) Control Plane Routing protocols with extensions (IS-IS,OSPF, BGP) SDN controller Data Plane MPLS (segment ID = label) IPv6 (segment ID = V6 address) Strict or loose path High cost Low latency Adj SID: 46 R1 SID: 1 R2 SID: 2 SID: Segment ID R4 SID: 4 R6 SID: 6 R7 SID: 7 R3 SID: 3 R5 SID: 5 Data Explicit loose path for low latency app No LDP, no RSVP-TE Introduce Segment Routing (3)

Strong Operator Partnership and Demand SPRING Working-Group All key documents are WG-status Over 25 drafts maintained by SR team Over 50% are WG status Over 75% have a Cisco implementation Several interop reports are available WEB SP Core/Edge SP Agg/Metro Large Enterprise Real customer deployment across market segments in CY15 Strong partnership with the Tier-1 SP and WEB customers: over 30 operators involved Strong commitment for standardization and multi-vendor support

Business Asks: Application-engineered Routing and Bandwidth Optimization Business Asks: Differentiate service for application needs Monetize the expensive peering links The Solution Application-engineered Routing How? controller intelligence + rapid network response in a simple and scalable way DC WAN 31 PEER ISP Low Lat, Low BW 50 Low latency Low bandwidth Default ISIS cost metric: 10 Program network 8 90% usage 40% High latency High bandwidth Controller Collect information from network Existing RSVP-TE traffic engineering is static, complex and not scale, which can’t meet the application-engineered requirement

Controller learn the network topology and usage dynamically Controller calculate the optimized path for different applications: low latency, or high bandwidth Controller just program a list of the labels on the source routers. The rest of the network is not aware: no signaling, no state information  simple and Scalable DC WAN 31 PEER Low Lat, Low BW 50 Low latency Low bandwidth Default ISIS cost metric: 10 Program network 8 90% usage 40% High latency High bandwidth Controller Collect information from network {16001, 16002, 124, 147} Node SID: Node SID: Adj SID: 124 Peering SID: 147 {16002, 124, 147} {124, 147} {147} The Solution: Segment Routing Application-engineered Routing and Bandwidth Optimization

The Challenging of the existing L2VPN Service Network inefficiency – Flood-and-learn, broadcast storm – Active/Standby forwarding, can’t achieve per-flow load balancing like L3 service – Signaling for pseudowire, not scalable Different operational models – L3VPN and L2VPN works in different way – Different type of the L2VPN: manual configuration, BGP auto-discovery, BGP signaling, LDP signaling, etc – MPLS data plane vs. IP data plane Lack of programmability and policy control – MAC learning happen at data plane – Can’t have policy control per MAC address – Difficult to be programmable

Why yet-another-VPN? Introducing MAC Routing: Ethernet VPN (EVPN) C-MAC: M1 Single active multi-homing All active multi- homing Control plane: BGP MAC Routing BGP advertise and learn the customer MAC address Data Plane: IP or MPLS, flexible Network Efficiency Common L2/L3 VPN Operational Mode Flexible Policy Control Consolidated VPN service with x-EVPN

What is x-EVPN ? EVPN is next generation all-in-one VPN solution 19 E-LAN (MP2MP L2VPN) E-LINE (P2P L2VPN) E-TREE (P2MP L2VPN) DC Fabric (IntraDC Overlay) IRB (L2/L3 Overlay) DCI (InterDC) IP-VPN (L3VPN)

Converge the VPN Service to x-EVPN Data Center 1 WAN/Core SP Acc/Agg Client SP DC bLea f Leaf Spine Data Center 2 DC Gateway service SP Edge DCI SP L2VPN & IP-VPN EoMPLS, VPLS (T-LDP, BGP signaling, BGP AD) DC Fabric Legacy VLAN, FP, Trill DCI VPLS, OTV IP-VPN DC Fabric EVPN (VXLAN: L2 and L3) SP L2VPN & IP-VPN EVPN/EVPN-VPWS (MPLS, PBB, VXLAN) DCI EVPN/IP-VPN (VXLAN, MPLS) Common BGP Control Plane Existing Evolution Inter-operability Smooth Migration

Agenda Evolving the SP Network Infrastructure The Technology Innovations ‒ Segment Routing ‒ x-EVPN The Architecture Evolution: ACE (Agile Carrier Ethernet)

Introduce the ACE (Agile Carrier Ethernet) Orchestration SDN Controller Orchestration SDN Controller Centralized service provisioning Work with existing network devices On Device Minimal but sufficient AN: Autonomic Networking SR: Segment Routing VPN services (BGP/T-LDPor static) Network as Platform Fully programmable Device is PnP component With minimal local intelligence Tail-f NSO WAE Tail-f NSO XRv+ODL WAE Phase 1 Phase 2 Now

Unified MPLS Model Complex Simple L2 Bridging Model Network Operation 802.1q/.1ad/.1a h REP, G.8032, STP Access Aggregation Access Flexible and scalable Multi-Service Architecture Unified operation across domains Optimized forwarding Complex to operate and manage Simple, plug & play It only supports Ethernet services Not scalable No A/A load balancing BUM Complex across L2/L3 domains … Fully distributed Layer 2 control plane Fully distributed IP/MPLS control plane SDN SDN Controller SDN Model API Aggregation Control Plane and Data Plane Separation Access The Existing Solutions … ? MPLS-TP

Our Vision: the Agile Carrier Ethernet Controller Open API Autonomic Network Infrastructure Service: Controller Is there middle ground? DistributedCentralized Balance ? ? Minimal but “Sufficient” distributed control plane on network nodes w Centralized intelligence on the SDN service controller Transport: Segment Routing Auto-discovery

Autonomic Networking: Secure, Plug-n-Play Registrar Dark Layer 2 Cloud Michael Steve AAA Misconfig / Routing Misconfig ` Plug-n-Play: New node use v6 link local address to build adjacency with existing nodes, no initial configuration is required Secure: New node is authenticated using its SUID, and then build encrypted tunnel with its adjacent nodes Always-on VOOB: Consistent reachability between Controller and network devices over Virtual Out-of- band management VRF. Even with user mis-configuration, the VOOB will still remain up

Aggregation Access Aggregation Core DC Unified MPLS with SR Isolated network domains BUT with common IP/MPLS technology using segment routing SDN controlled inter-domain for end-to-end routing Common operational model and common policy control No network boundary due to different technologies, simple solution for network high availability Back compatible with existing network: LDP/RSVP-TE, RFC 3107 Metro island DC island Core island A B GW1 GW2 Tail-f, WAE A  B: [GW1, GW2, B] B  A [GW2, GW1, A] ACE Transport: Unified MPLS with Segment Routing Tail-f, WAE

Aggregation Access Aggregation Core Unified VPN simple service model P2P L2VPN: provisioned by controller MP L2VPN: x-EVPN technology L3VPN: centralized on the GW node using PWHE virtual interface IP-VPN A B GW1 GW2 ACE Service: Unified VPN Service Model PW PWHE x-VPN PW P2P L2VPN MP L2VPN L3VPN VPN service provisioning Tail-f

Aggregation Access Aggregation Core Controller run centralized service control plane (BGP, T-LDP) on-behalf-of network nodes Controller program the RIB/FIB to the network node for the optimized forwarding Tail-f NSO controller for end-to-end service provisioning A B GW1 GW2 ACE Phase 2: Centralized Control Plane w Controller x-VPN, IP-VPN Controller Tail-f VPN service provisioning Controller One Single XR Virtual Router

But wait, how about service and service SLA? Does it support all the services ? Does it support high availability? How scalable it’s? how fast to program in a large network How does it inter-operate with my existing network? … Is Openflow the answer? SDN Controller OpenFlow Flow Tables Commoditized forwarding box The classic SDN story: Full control plane and data plane separation Network box has no intelligence Network is simplified dramatically

Our Vision (5 years ago): nV Satellite Satellite Protocol Satellite Host Centralized control plane (Controller) Simple port extender (OF switch) AND, full service and service SLA support All existing service by IOS-XR asr9k Network fast reroute Regular router function, inter-operate with existing network Similar operation mode nV Satellite: Full control plane and data plane separation Centralized control plane on Host Satellite box has no/little intelligence One virtual Router But …

The Market Adoption of the nV Satellite Solution One of the most successful innovation from Cisco Extremely Fast Ramp: 300+ customers worldwide in 2+ years Major Tier-1 SP across markets: Cable/MSO, Telco, Mobile, Carrier Ethernet, Enterprise

nV Satellite Evolution Topology expansion Feature offload High Dense 10G Satellite

The Evolution of the nV Satellite Architecture Light feature offload Provisioning with Netconf/yang Local FIB download Optimized forwarding Standard based fabric Any network topology Open, Standard solution 3 rd party device, minimal effort as satellite Feature offload Fully coupled with Host function Big engineering effort Centralized forwarding on Host No local forwarding Proprietary SACP, MACinMAC fabric Limited topologies support Cisco proprietary solution Big effort to support new HW as satellite Centralized service control plane on XRv XRv scale out Centralized control plane on Host Control plane scale limited by Physical chassis Existing nV SatelliteController based nV System

ODL FB Standard APIs FB Callisto: Controller-based nV System Concept FIB/RIB programming Feature provisioning One Single XR Virtual Router XR Control Plane Controller Forwarding Boxes Single interface to provision FB Add new BW capacity Simple operation: PnP CAPEX Saving with limited features and low scale on the FB Controller Provisioning RIB distribution TelemetryFabric manager

Future Centralized Provisioning Now Evolving to the Future Network Infrastructure Network Infrastructure as Platform Tail-f NSO WAE XRv+ODL ODL+App Tail-f NSO WAE Tail-f NSO Centralized Provisioning Controller Intelligence Protocol Evolution Segment Routing, x-EVPN, Autonomic Networking