Cisco Open Network Architecture Vision

PowerPoint Presentation

Marketing PresentationSpeaker NameDesignationDate: 00/00/0000

Marketing PresentationSpeaker NameDesignationDate: 00/00/0000

Evolving the SP Network InfrastructureDennis CaiDistinguished Engineer, SP Infrastructure Team05/2015

AgendaEvolving the SP Network InfrastructureThe Technology Innovations Segment Routing x-EVPNThe Architecture Evolution: ACE (Agile Carrier Ethernet)

Storage

Network

Evolved Programmable Network

Compute

Evolved Service Platform

Applications / OSS/BSS

Device ModelService ModelCisco Open Network Architecture Vision

3

Data Center SDN(APIC, VTS)Metro access Control(WAE, ODL)

Metro and AccessWANData CentreDomain / functional APIs

CPE

Multi-layer WAN SDN(WAE, ODL)

Cross Domain Orchestration (Tail-f NSO)Transport OpticalCiscos Unified SDN Architecture for SP Network Infrastructure

CPE

EPNESP

FutureOperational ComplexityVendor Specific OSIntegrated HW and SWNowSmooth Transition to the Future Network InfrastructureInter-operableBack-compatibleMulti-servicesService SLA?Operation, VisibilityService Agility: Fully ProgrammableOptimized and Application-aware RoutingPnP of the BW capacityNetwork Infrastructure as Platform

Device-CentricInvestment protection

5

Lets start with SDN driven by different business interestCP/DP separationNFVwhite boxopenflowOpenstackControllersODL Programmable

6

What Our Customers Care?Services, ApplicationDevice-centric Network as PlatformOPEN API

Low OPEX and CAPEX

Service agilityBusiness outcome

RoutersSwitchesRRSSIndividual boxes, Cisco, Juniper, XR, XE, J, A, H

FBFBFBFBControllerBox is PnP, with limited local function

7

From Device Centric to Network-as-PlatformData PlaneControl PlaneConfig PlaneDevice centric view

OrchestrationSDN ControllerNetwork-wide viewNetwork-wide orchestration replaces the individual device config. This allows network wide service definition and deploymentThe 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 forwardingEfficient route distribution Rapid convergence with local failure detection and repairLocal features: L1 features, OAM/PM, QoS, Timing, mcast replication

It will be a long journey

OrchestrationSDN Controller

Orchestration

OrchestrationSDN ControllerCentralized service provisioning Work with existing network devicesReduced Control Plane on DeviceAN: Autonomic NetworkingSR: Segment RoutingX-EVPNNetwork as PlatformFully programmableDevice is PnP componentWith minimal local intelligence on deviceTail-f NSOTail-f NSOWAETail-f NSOXRv+ODLWAE

NextFuture PhaseNowFull control plane on deviceReduced control plane on deviceMinimal control plane on device


Introduce Segment Routing (1)Segment Routing is a Source RoutingThe 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 simpleSource router intelligence is programmed by the external controllerApplication-engineered routing Seamless integration between network and controllersSimplify the MPLS and Routing

11

Introduce Segment Routing (2)

Is there middle ground?

DistributedCentralized

RightBalanceIts right balance between distributed routing intelligence on the router and the centralized intelligence on the controllerRouter keep minimal local intelligence for features such as fast local re-route, shortest path forwarding within the local routing domainComplex inter-domain routing and application-aware routing are moved to controller to keep router as simple as possible

12

Data7

Dynamic pathExplicit pathPaths optionsDynamic (STP computation)Explicit(expressed in the packet)Control PlaneRouting protocols with extensions(IS-IS,OSPF, BGP)SDN controllerData PlaneMPLS (segment ID = label)IPv6 (segment ID = V6 address)

Strict or loose pathHigh costLow latencyAdj SID: 46R1SID: 1R2SID: 2SID: Segment IDR4SID: 4R6SID: 6R7SID: 7R3SID: 3R5SID: 5Data7464

Explicit loose path for low latency appNo LDP, no RSVP-TEIntroduce Segment Routing (3)

13

Strong Operator Partnership and Demand

SPRING Working-GroupAll key documents are WG-statusOver 25 drafts maintained by SR teamOver 50% are WG statusOver 75% have a Cisco implementationSeveral interop reports are available

WEB

SP Core/Edge

SP Agg/Metro

Large EnterpriseReal customer deployment across market segments in CY15Strong partnership with the Tier-1 SP and WEB customers: over 30 operators involvedStrong commitment for standardization and multi-vendor support

14

Business Asks:Application-engineered Routing and Bandwidth OptimizationBusiness Asks:Differentiate service for application needsMonetize the expensive peering linksThe SolutionApplication-engineered RoutingHow? controller intelligence + rapid network response in a simple and scalable wayDC

10

11

12

13

14

2

4

6

5

7

WAN

3

1

PEERISPLow Lat, Low BW

50Low latencyLow bandwidthDefault ISIS cost metric: 10

Programnetwork

890% usage40%High latencyHigh bandwidthController

Collect information from network

Existing RSVP-TE traffic engineering is static, complex and not scale, which cant meet the application-engineered requirement

15

Controller learn the network topology and usage dynamicallyController calculate the optimized path for different applications: low latency, or high bandwidthController 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 ScalableDC

10

11

12

13

14

2

4

6

5

7

WAN

3

1

PEERLow Lat, Low BW

50Low latencyLow bandwidthDefault ISIS cost metric: 10

Programnetwork

890% usage40%High latencyHigh bandwidthController

Collect information from network

{16001, 16002, 124, 147}Node SID: 16001Node SID: 16002Adj SID: 124Peering SID: 147

{16002, 124, 147}

{124, 147}

{147}The Solution: Segment RoutingApplication-engineered Routing and Bandwidth Optimization

16

The Challenging of the existing L2VPN ServiceNetwork inefficiencyFlood-and-learn, broadcast stormActive/Standby forwarding, cant achieve per-flow load balancing like L3 serviceSignaling for pseudowire, not scalableDifferent operational modelsL3VPN and L2VPN works in different wayDifferent type of the L2VPN: manual configuration, BGP auto-discovery, BGP signaling, LDP signaling, etcMPLS data plane vs. IP data planeLack of programmability and policy controlMAC learning happen at data planeCant have policy control per MAC addressDifficult to be programmable

First, lets have a quick review of some of the challenging of the L2VPN service:

17

Why yet-another-VPN?Introducing MAC Routing: Ethernet VPN (EVPN)

IP or MPLS

PE1CE1

PE2

PE3CE3

PE4

C-MAC:M1Single active multi-homingAll active multi-homingControl plane: BGP MAC RoutingBGP advertise and learn the customer MAC addressData Plane: IP or MPLS, flexibleNetwork EfficiencyCommon L2/L3 VPN Operational ModeFlexible Policy ControlConsolidated VPN service with x-EVPN

18

What is x-EVPN ?EVPN is next generation all-in-one VPN solution

19E-LAN(MP2MP L2VPN)E-LINE(P2P L2VPN)E-TREE(P2MP L2VPN)

EVPN VPWS

(PBB-) EVPN

EVPNDC Fabric(IntraDC Overlay)IRB(L2/L3 Overlay)DCI(InterDC) IP-VPN(L3VPN)

EVPNDCI

EVPN-IRB

EVPN-Overlay

EVPN ETREE

EVPN-IRB

VPLS

PW

4364

VPLS-ETREE

VPLS,OTV

Converge the VPN Service to x-EVPN

Data Center 1

WAN/CoreSP Acc/AggClient

SPDC

bLeafbLeafLeafLeaf

Spine

Data Center 2

DC GatewayserviceSP EdgeDCI

SP L2VPN & IP-VPNEoMPLS, VPLS (T-LDP, BGP signaling, BGP AD)DC FabricLegacy VLAN, FP, TrillDCIVPLS, OTVIP-VPNDC FabricEVPN (VXLAN: L2 and L3)SP L2VPN & IP-VPNEVPN/EVPN-VPWS (MPLS, PBB, VXLAN)DCIEVPN/IP-VPN(VXLAN, MPLS)Common BGP Control PlaneExistingEvolutionInter-operabilitySmooth Migration

20


Introduce the ACE (Agile Carrier Ethernet)

OrchestrationSDN Controller

Orchestration

OrchestrationSDN ControllerCentralized service provisioning Work with existing network devicesOn Device Minimal but sufficientAN: Autonomic NetworkingSR: Segment RoutingVPN services (BGP/T-LDPor static)Network as PlatformFully programmableDevice is PnP componentWith minimal local intelligenceTail-f NSOTail-f NSOWAETail-f NSOXRv+ODLWAE

Phase 1Phase 2Now

Unified MPLS Model

ComplexSimpleL2 Bridging Model

Network Operation

802.1q/.1ad/.1ahREP, G.8032, STP

AccessAggregationAggregationAccess

Flexible and scalable Multi-Service ArchitectureUnified operation across domainsOptimized forwardingComplex to operate and manage

Simple, plug & playIt only supports Ethernet servicesNot scalableNo A/A load balancingBUMComplex across L2/L3 domainsFully distributed Layer 2 control plane

Fully distributed IP/MPLS control plane

SDNSDN Controller

SDN ModelAPI

AggregationControl Plane and Data Plane SeparationAccessThe Existing Solutions ?MPLS-TP

23

Our Vision: the Agile Carrier Ethernet

ControllerOpen APIAutonomic Network Infrastructure

Service: ControllerIs there middle ground?

DistributedCentralized

Balance

??Minimal but Sufficient distributed control plane on network nodesw Centralized intelligence on the SDN service controllerTransport: Segment RoutingAuto-discovery

24

Autonomic Networking: Secure, Plug-n-Play

Registrar

Dark Layer 2 Cloud

MichaelSteve

AAA Misconfig / Routing Misconfig`

Plug-n-Play: New node use v6 link local address to build adjacency with existing nodes, no initial configuration is requiredSecure: New node is authenticated using its SUID, and then build encrypted tunnel with its adjacent nodesAlways-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

AggregationAccess

AccessAggregationCore

DCUnified MPLS with SRIsolated network domains BUT with common IP/MPLS technology using segment routingSDN controlled inter-domain for end-to-end routingCommon operational model and common policy controlNo network boundary due to different technologies, simple solution for network high availabilityBack compatible with existing network: LDP/RSVP-TE, RFC 3107

Metro islandMetro islandDC islandCore islandABGW1GW1GW2GW2

Tail-f, WAEAB: [GW1, GW2, B]B A [GW2, GW1, A]ACE Transport: Unified MPLS with Segment Routing

Tail-f, WAE

26

AggregationAccess

AccessAggregationCoreUnified VPN simple service modelP2P L2VPN: provisioned by controllerMP L2VPN: x-EVPN technologyL3VPN: centralized on the GW node using PWHE virtual interface

IP-VPNABGW1GW1GW2GW2ACE Service: Unified VPN Service Model

PWPWPWHEPWHEx-VPN

PWPWPWP2P L2VPNMP L2VPNL3VPN

VPN service provisioningTail-f

27

AggregationAccess

AccessAggregationCoreController run centralized service control plane (BGP, T-LDP) on-behalf-of network nodesController program the RIB/FIB to the network node for the optimized forwardingTail-f NSO controller for end-to-end service provisioningABGW1GW1GW2GW2ACE Phase 2: Centralized Control Plane w Controllerx-VPN, IP-VPN

Controller

Tail-fVPN service provisioningControllerOne Single XR Virtual RouterOne Single XR Virtual Router

28

But wait, how about service and service SLA?Does it support all the services ?Does it support high availability?How scalable its? how fast to program in a large networkHow does it inter-operate with my existing network?Is Openflow the answer?

SDN ControllerOpenFlowFlow Tables

Commoditized forwarding boxThe classic SDN story:Full control plane and data plane separationNetwork box has no intelligenceNetwork is simplified dramatically

Our Vision (5 years ago): nV Satellite

Satellite ProtocolSatellite Host

Centralized control plane(Controller)

Simpleport extender(OF switch)AND, full service and service SLA supportAll existing service by IOS-XR asr9kNetwork fast rerouteRegular router function, inter-operate with existing networkSimilar operation modenV Satellite:Full control plane and data plane separationCentralized control plane on HostSatellite box has no/little intelligence

One virtual RouterBut

The Market Adoption of the nV Satellite SolutionOne of the most successful innovation from CiscoExtremely Fast Ramp: 300+ customers worldwide in 2+ yearsMajor Tier-1 SP across markets: Cable/MSO, Telco, Mobile, Carrier Ethernet, Enterprise

nV Satellite EvolutionTopology expansion Feature offload

High Dense 10G Satellite

The Evolution of the nV Satellite ArchitectureLight feature offloadProvisioning with Netconf/yangLocal FIB downloadOptimized forwardingStandard based fabricAny network topologyOpen, Standard solution3rd party device, minimal effort as satellite Feature offloadFully coupled with Host functionBig engineering effortCentralized forwarding on HostNo local forwardingProprietary SACP, MACinMAC fabricLimited topologies supportCisco proprietary solutionBig effort to support new HW as satelliteCentralized service control plane on XRvXRv scale out Centralized control plane on HostControl plane scale limited by Physical chassisExisting nV SatelliteController based nV System

ODLFB

FBFBStandard APIsFBFBCallisto: Controller-based nV System ConceptFIB/RIB programmingFeature provisioningOne Single XR Virtual RouterXR Control Plane

ControllerForwarding BoxesSingle interface to provisionFBAdd new BW capacitySimple operation: PnPCAPEX Saving with limited features and low scale on the FBControllerProvisioningRIB distributionTelemetryFabric manager

34

FutureCentralized ProvisioningNowEvolving to the Future Network InfrastructureNetwork Infrastructure as PlatformTail-f NSOWAEXRv+ODLODL+AppTail-f NSOWAETail-f NSOCentralized ProvisioningController IntelligenceProtocol Evolution Segment Routing, x-EVPN, Autonomic Networking

35

Q&A

36

TDMTDMTDMTDM

Documents

Cisco Open Network Architecture Vision