Jiri Chaloupka - Technical Marketing Engineer

Jiri Chaloupka - Technical Marketing Engineer
Network Architecture with Software Programmability Cisco Metro Fabric Design Jiri Chaloupka - Technical Marketing Engineer released: 10/2017

Cisco SP Fabric Designs principals: Simple, Scalable, Automatable
Network Location Metro & Access Core Peering Designs Metro Fabric Core Fabric Peering Fabric CLOS Fabric Automation SR/EVPN Telemetry and Analytics YANG data models Building Blocks CLOS Fabric in SP Routed Backbone, Metro/Agg …

Cisco Metro Fabric - High-Level Design
Cisco Live 2016 Cisco Metro Fabric - High-Level Design 7/1/2018 ASR9000 Segment Routing End-to-End TI-LFA SRTE Policy Programmability (XTC) IOS-XR common OS ASR900 -> NCS5500 ASR920 IOS-XR based access PE Layer IGP1+SR Aggregation ASR903 RSP3 -> NCS5500 ZTP/ZTD Telemetry N/Y (ops) Overlay Service Provisioning (NSO) Data Path Programming (XTC) PCEP BGP-SRTE N/Y (prov.) IGP2+SR Interconnecting Not Otherwise Specified Fabric NG Metro NG Metro Access OSTCD sBGP (L3VPN, EVPN) N/Y = NETCONF/YANG OSTCD = Other Service Terminating Compass Design

Cisco Metro Fabric - High-Level Design Access Simplification
Cisco Live 2016 7/1/2018 Cisco Metro Fabric - High-Level Design Access Simplification ASR9000 Segment Routing End-to-End TI-LFA SRTE Policy Programmability (XTC) IOS-XR common OS ASR900 -> NCS5500 ASR920 IOS-XR based access PE Layer ASR903 RSP3 -> NCS5500 ZTP/ZTD Telemetry N/Y (ops) IGP1+SR Access Overlay Service Provisioning (NSO) Data Path Programming (XTC) PCEP BGP-SRTE N/Y (prov.) Interconnecting Not Otherwise Specified Fabric NG Metro NG Metro OSTCD sBGP (L3VPN, EVPN) N/Y = NETCONF/YANG OSTCD = Other Service Terminating Compass Design

Cisco Metro Fabric: what is?
Compass Metro Design is a design: For SP Metro Network (Access, Aggregation) and Mobile Backhauling Built on top the successful Cisco Evolved Programmable Network (EPN 5.0) architecture Evolution of existing Unified MPLS Architecture Transport and Services Simplification Network Programmability with Segment-Routing and XTC Automated Service Provisioning with NSO Unified BGP based control plane for Layer 2 (EVPN) and L3 services (BGP L3VPN) Based on IOS-XR end-to-end Enhanced and simplified operations with Automation and Analytics

Cisco Metro Fabric: who is this for?
Compass Metro Design targets customers who: Need a lean, simple and scalable design that will support future growth Need to build a network ready for 5G and IoT Are looking for an SDN ready solution Want to evolve their existing Unified MPLS Network Want to offer new services with guarantees SLAs Want an industry leading/future proof architecture

Compass Metro Fabric Compass Design Building Blocks
CLOS Fabric Automation Segment Routing BGP VPN Industry lead ASR9K Highly dense and scalable NCS 5500 Programmability and analytics with YANG data models and telemetry Unified Forwarding Plane with Explicit Path Control and Traffic Engineering Common Control Plane for L2, L3 and IRB

Unified MPLS Transport Model Baseline
Fixed Access Network IS-IS L1 Aggregation Network IS-IS L2 Core Network IS-IS L2 Aggregation Network IS-IS L2 Mobile Access Network IS-IS L1 AS-B AS-A AS-C Inline RR PAN  next-hop-self   next-hop-self  AGN-ASBR  next-hop-self  CN-ASBR  next-hop-self  CN-ASBR  next-hop-self  AGN-ASBR Inline RR PAN  next-hop-self  eBGP IPv4+label eBGP IPv4+label MTG CSG FAN AGN-RR iBGP IPv4+label iBGP IPv4+label CN-RR AGN-RR RR RR RR iBGP IPv4+label iBGP IPv4+label CSG FAN iBGP IPv4+label MTG AGN-SE CSG FAN iBGP Hierarchical LSP eBGP LSP iBGP Hierarchical LSP eBGP LSP iBGP Hierarchical LSP LDP LSP LDP LSP LDP LSP LDP LSP LDP LSP

Cisco Metro Fabric Overview
NSO – End-to-End Service Provisioning XTC/WAE- End-to-End Path optimization with SLAs BGP-LS PCEP Netconf/Yang Netconf/Yang BGP-LS PCEP P Nodes NG Metro Fabric NG Metro Fabric Core Network Access Node Access Node ABR Node ABR Node Metro Area 01 Metro Area 02 Core Network IGP with SR Extensions (TI-LFA) IGP with SR Extensions (TI-LFA) IGP with SR Extensions (TI-LFA) Services: BGP - L3VPN/L2VPN(EVPN), point-to-point services static PW Transport: Segment-Routing with TI-LFA

Evolve Networks Toward Agility and Speed
NSO XTC Cloud Scale Networking Central Office Access Metro Network Domain Core Network Domain Data Center Domain Compute Leaf Spine VNF EVPN/L3VPN Services Segment Routing Automate E2E Cross-domain automation with model-driven programmability and streaming telemetry Virtualize Transform the CO into a data center to enable distributed service delivery and speed up service creation Simplify Unified underlay with Segment Routing What Service Providers clearly need is a solution where the network infrastructure facilitates the implementation of new services wherever that makes the most sense – centralized vs. distributed. This solution, we call it – Unified “Network as a fabric”. Let’s see how that works. The first step is to simplify underlay and overlay network infrastructure. - Segment Routing is the de-facto technology to make Service Providers’ infrastructure SDN-ready. Segment Routing adoption started in the WAN but is now spreading further across the network – from the Access through Metro/WAN up to Data Centers. This unified underlay forwarding plane paradigm brings simplicity and consistency across network domains but also comes with network services inherent to Segment Routing – 50ms protection (TI-LFA), low-latency path, disjoint path … - Ethernet VPN (EVPN) enables integrated Layer 2 and Layer 3 services over Ethernet with multi-homing in a scalable and simplified fashion. EVPN is based on border gateway protocol (BGP) and based on industry standards. EVPN provides separation between the data plane and the control plane - allowing for the use of different encapsulation mechanisms in the data plane while maintaining the same control plane. EVPN can be deployed in the Data Center, at the DC Interconnect as well as in Metro/Core networks. It provides a Unified Overlay Control Plane. The second step is to automate the E2E network infrastructure. Two important drivers contribute to it: - First driver – streaming telemetry provides you with fine-grained visibility into what’s happening in your network infrastructure. You can only control what you understand ! - Second driver – model-driven programmability helps you transition from manual operations (CLI) to programmatic interfaces (APIs). Our commitment here is to provide the most comprehensive set of data models (IETF, OpenConfig, Native YANG models) along with model-driven APIs and tools to accelerate the adoption of software automation. The third and final step is to augment Central Offices capabilities with compute resources to increasingly use VNFs to deliver new services. Central Offices become distributed Data Centers Service Providers can leverage as a competitive differentiator to instantiate services that benefit from being localized closer to End-Users. (latency, delay – sensitive services) With this last step, the network clearly becomes a fabric connecting Central Offices to Centralized Data Centers enabling Service Providers to instantiate services wherever that makes the most sense.

End-to-End network design with Cisco IOS XR
Consistent Operational Efficiency and Feature Set Across the Metro Core and DC Data Center Domain Central Offices XRv9000 IOS XR DCI NCS 1002 Metro Network Domain Core Network Domain Data Center Domain NCS 5516 NCS 5501/2 NCS 5508 NCS 5501/2 NCS 5516 Data Center Networking Compute UCS ASR 9K ASR 9K DCI NCS 1002 Data Center Domain All of this is actually made possible by our IOS XR Operating System. Cloud-scale enhancements to IOS XR we announced one year ago and we augmented since then – ruthless automation, visibility and control, simplification and open innovation - bring you significant operational improvements across your entire network infrastructure. All the platforms you can see here – in blue our legacy platforms and in green the platforms we announce today – are powered by IOS XR. We are thus offering you the flexibility and agility to deploy the right hardware depending on their place in the network architecture and I want to outline here that the richness of our HW portfolio does not come at the expense of feature sets and operational consistency. Cisco is uniquely positioned to deliver this “Network as a Fabric”.

Cisco Metro Fabric - Protocol Simplification
Unified IP/MPLS Metro Fabric Apps Applications Applications Apps APIs CLIs Provisioning NSO Path Computation/ WAN optimization XTC/WAE Network Management BGP BGP-LU T-LDP RSVP-TE MPLS LDP IP IGP Controller/ Orchestration APIs Router BGP T-LDP/Static IP IGP/SR Router

Segment Routing Segment Routing – Technical view
Data Plane MPLS (segment labels) IPv6 (+ SR extension header) Path expressed in the packet Data Dynamic path Control Plane Routing protocols with extensions (IS-IS,OSPF, BGP) SDN controller (BGP LS, PCEP, NETCONF/YANG) Explicit path Paths options Dynamic (STP computation) Explicit (expressed in the packet)

IGP Prefix Segment 1 2 5 3 4 Example 1: Best Path 16005 16005 16005
Signaled by ISIS/OSPF Minor extensions to existing link-state routing protocols Shortest-path to IGP prefix Equal Cost MultiPath (ECMP)-aware Global significance in SR domain Label = SRGB + Index SRGB = Segment Routing Global Block Default SRGB: 16,000 – 23,999 Advertised as index /32 1 2 16005 16005 16005 5 16005 16005 3 4 16005 All nodes use default SRGB 16,000 – 23,999

IGP Prefix Segment 1 2 5 3 4 Example 2: ECMP 16004 16004 16004
Signaled by ISIS/OSPF Minor extensions to existing link-state routing protocols Shortest-path to IGP prefix Equal Cost MultiPath (ECMP)-aware Global significance in SR domain Label = SRGB + Index SRGB = Segment Routing Global Block Default SRGB: 16,000 – 23,999 Advertised as index 1 2 16004 16004 5 16004 16004 16004 3 4 /32 16004 All nodes use default SRGB 16,000 – 23,999

IGP Adjacency Segment 1 2 5 3 4 24025 24024 Signaled by ISIS/OSPF
Adj to 5 24025 Signaled by ISIS/OSPF Minor extensions to existing link-state routing protocols Forward on IGP adjacency Local significance Automatically allocated by router 1 2 Adj to 4 24024 5 3 4

Combining IGP Segments
16004 24045 Packet to 5 Signaled by ISIS/OSPF Steer traffic on any path through the network Path is specified by list of segments in packet header, a stack of labels No path is signaled No per-flow state is created 1 2 5 24045 Packet to 5 3 4 16004 24045

MPLS Data Plane Operations
IPv4: /32 or IPv6: 2001::0101:0104/128 Prefix-SID 16004 Segment 16004 1 2 3 4 Push Swap Pop - Assumptions: SR enabled on all nodes LDP not enabled or SR- preferred on Node1 Payload 16004 Payload 16004 Payload Payload Node4 advertises its loopback v4 or v6 address with attached prefix-SID 16004 IPv4 address: /32 IPv6 prefix: 2001::0101:0104/128 Node4 requests default PHP functionality

Simple and Efficient Transport of MPLS services
MPLS services ride on prefix segments Simple, one less protocol to operate (LDP) MP-BGP 3 4 CE PE PE CE 7 1 2 8 /32 Prefix-SID 16002 /30 2001::a00:0/126 5 6 vrf RED SR Domain vrf RED

Anycast Prefix Segment ID (SID)
Same prefix advertised by multiple nodes Traffic forwarded to one of Anycast prefix- SIDs based on best IGP path If primary node fails, traffic is auto re-routed to other node 100 12 10 2 4 1 7 16100 13 3 6 5 11 100 14 DC (BGP-SR) WAN (IGP-SR) PEER

SR Segments IGP Prefix Segment IGP Adjacency Segment
SRGB: Segment Routing Global Block: default [16000 – 23999] Signaled by ISIS/OSPF Minor extensions to the existing link-state routing protocols (OSPF and IS-IS) Shortest-path to the IGP prefix Global in SR domain SRGB + Index => = 16005 DC (BGP-SR) 10 11 12 13 14 2 4 6 5 7 WAN (IGP-SR) 3 1 PEER 16005 IGP Prefix Segment DC (BGP-SR) 10 11 12 13 14 2 4 6 5 7 WAN (IGP-SR) 3 1 PEER 124 Signaled by ISIS/OSPF Minor extensions to the existing link-state routing protocols (OSPF and IS-IS) Forward on the IGP adjacency Local Automatically allocated by the router IGP Adjacency Segment

Binding-SID – Stitching – Illustration
BSID: 30410 BSID: 30710 1 2 3 4 5 6 7 8 9 10 All Nodes SRGB [16,000-23,999] Prefix-SID NodeX: 1600X Binding-SID XY: 300XY 14 Node 10 30410 16004 16003 Node 10 30710 16007 16006 Node 10 30410 16004 Node 10 30710 16007 Node 10 16010 16009 410 Node 10 30410 Node 10 30710 Node 10 16010 Node 10 Assume Node1 can’t push 8 labels to go to Node10 “compress” label stack by stitching SRTE Policies: Node1 pushes: 2 labels to go to Node4 Binding-SID to go to Node10 Node4 pops Binding-SID and pushes: 2 labels to go to Node7 Node7 pops Binding-SID and pushes 2 labels to go to Node10

Cisco Metro Fabric - Transport IGP-SR/TI-LFA/SR-LDP_co-existence Configuration Example
router isis 1 address-family ipv4 unicast metric-style wide segment-routing mpls ! interface Loopback0 prefix-sid prefix-sid index 1 router ospf 1 router-id segment-routing mpls segment-routing forwarding mpls area 0 interface Loopback0 passive enable prefix-sid index 1 IGP-SR TI-LFA SR/LDP Co-existence LDP->SR migration

router isis 1 address-family ipv4 unicast metric-style wide segment-routing mpls ! interface Loopback0 prefix-sid prefix-sid index 1 router ospf 1 router-id segment-routing mpls segment-routing forwarding mpls area 0 interface Loopback0 passive enable prefix-sid index 1 IGP-SR router isis 1 interface GigabitEthernet0/0/0/2 address-family ipv4 unicast fast-reroute per-prefix fast-reroute per-prefix ti-lfa router ospf 1 fast-reroute per-prefix fast-reroute per-prefix ti-lfa TI-LFA SR/LDP Co-existence LDP->SR migration

router isis 1 address-family ipv4 unicast metric-style wide segment-routing mpls ! interface Loopback0 prefix-sid index 1 router ospf 1 router-id segment-routing mpls segment-routing forwarding mpls area 0 interface Loopback0 passive enable prefix-sid index 1 IGP-SR router isis 1 interface GigabitEthernet0/0/0/2 address-family ipv4 unicast fast-reroute per-prefix fast-reroute per-prefix ti-lfa router ospf 1 fast-reroute per-prefix fast-reroute per-prefix ti-lfa TI-LFA router isis 1 address-family ipv4 unicast segment-routing mpls sr-prefer router ospf 1 segment-routing mpls segment-routing sr-prefer SR/LDP Co-existence LDP->SR migration

The next wave What is segment routing?
The 2 faces of segment routing The next wave What is segment routing? An LS IGP protocol extension bringing network simplification/optimization An IP/MPLS architecture designed with SDN in mind No LDP Lighter protocol suite Less adjacencies, less states to maintain No IGP to LDP synchronization Eliminates delays in activating a path Topology independent fast reroute using post convergence back up path 50 ms protection no microloops 100% coverage of network topologies Easy troubleshooting Right balance between distributed intelligence and centralized optimization and programming SR-TE Wide applications (SP, OTT/Web, GET) across (WAN, Metro/Agg, DC) MPLS and IPv6 dataplanes SDN controller Centralized-only Balance Distributed-only Mention on traffic engineering in simple path

BGP-LS Overview Optimal Path Computation for Multi-area TE
Solution is BGP, not IGP. BGP-LS is an address-family afi=16388, safi=71 Defined to carry IGP link-state database via BGP Supports both IS-IS and OSPF Delivers topology information to outside agents Domain 1 Domain 2 Domain 0 BGP-LS Traffic Engineering Databse (TED) RR PCE

PCEP Architectural Introduction
Cisco Live 2014 7/1/2018 Path computation Large, multi-domain and multi-layer networks Path computation element (PCE) Computes network paths (topology, paths, etc.) Stores TE topology database (synchronized with network) May initiate path creation Stateful - stores path database included resources used (synchronized with network) Path computation client (PCC) May send path computation requests to PCE May send path state updates to PCE Used between head-end router (PCC) and PCE to: Request/receive path from PCE subject to constraints State synchronization between PCE and router Hybrid CSPF PCEP PCE TED LSP DB PCC Open/Close/Keepalive PCC PCE Open/Close/Keepalive Request PCC PCE Reply Notification PCC PCE Notification

XR Transport Controller (XTC)
An IOS XR-powered Stateful Path Computation Element (PCE) Multi-Domain topology Collection Real-time reactive feed Computation Native SR-TE algorithms backed by extensive scientific research1 SR PCE North-Bound API Multi-Domain Topology Computation “Collection” BGP-LS ISIS / OSPF “Deployment” PCEP We are VERY excited at Cisco to introduce XTC to the market For many years, an IOS-XR router could act as a Path Computation Element Client (or PCC) And NOW we are releasing the ability to ALSO act as a PCE server and in particular a Segment Routing PCE … XTC is able to both collect the network topology using standards-based protocols such as BGP-LS And subsequently, is able to COMPUTE and DEPLOY SR paths through the network The algorithms used by XTC to perform this computation have been built from scratch to fully benefit from the key characteristics of Segment Routing Worth noting is that this FUNCTION can be hosted directly on a physical device or a virtual router SIGCOMM 2015 whitepaper

WAN Automation Engine (WAE)
Multi-layer, multi-vendor network model for path visibility and path computation APIs for planning, optimization, forecasting and traffic engineering WAE is NOT a controller – but leverages controllers WAN Automation Engine (WAE) WAE is a well-know software product to many of our SP customers It builds a multi layer (IP and Optical), multi-vendor network model that provides visibility, simulation and optimization capabilities for path computation Through APIs, WAE alo enables applications via a programmatic interface to this network model WAE is not a controller but instead leverages controllers and orchestrators like XTC and NSO to program to the network WAE Network Model

L2VPN Technologies Evolution
Native L2 Bridging Technologies .1ad/qinq: High VLAN scale .1ah: High VLAN and MAC scale 802.3 802.1Q 802.1ad qinq Trill 802.1ah PBB 802.1ad qinq 802.3 802.1Q L2VPN Technologies DC Overlay EVPN (Ethernet VPN) L2VPN: P2P or MP Overlay L2 over MPLS EoMPLS, VPLS/PBB-VPLS L2 over IP L2TPv3 VXLAN NV-GRE STT From MAC Bridging to MAC Routing

EVPN - End-to-End Control-Plane
Common EVPN Control Plane based on BGP: EVPN, PBB-EVPN, EVPN-VPWS Evolution: IP, MPLS (IGP/SR), MPLS-PBB IP,MPLS,VXLAN IP,MPLS,VXLAN Data Center Network Service Provider Network overlap Leaf VM PE1 DCI Spine Leaf VM A1 Acess WAN/Core Spine PE2 DCI Leaf VM Existing Solution: L2/L3VPN (BGP,T-LDP) - VPLS, EoMPLS VPLS, OTV Trill, Fabric-Path IP, IGP, MPLS (LDP), RSVP-TE, BGP-LU IP, MPLS, L2 L2, STP, VLAN

EVPN Next generation network services
Single service for any application E2E control and automation across domains EVPN ELINE ELAN ETREE L3 VPN DC Fabric DCI VPWS VPLS P2MP VPLS RFC 2547 VXLAN VPLS / L3 VPN DC Agg Core Access SR SR-TE MPLS VXLAN EVPN Optimized CapEx: - Open Standards & Multi-vendor Active-Active multi-homing Enhanced load balancing Reduced OpEx: Integrated L2 & L3 service, any application: faster time to market, certification E2E control and automation Increased Customer Value Inter-domain SLA, faster convergence Better stability: no flood Granular policy control xEVPN family introduces next generation solutions for Ethernet services BGP control-plane for Ethernet Segment and MAC distribution and learning over MPLS core Same principles and operational experience of IP VPNs

What is EVPN? EVPN-VPWS P2P Multipoint EVPN PBB-EVPN RFC 7432 RFC 7623 draft-ietf-bess-evpn-vpws EVPN family introduces next generation solutions for Ethernet services BGP control-plane for Ethernet Segment and MAC distribution and learning over MPLS core Same principles and operational experience of IP VPNs No use of Pseudowires Uses MP2P tunnels for unicast Multi-destination frame delivery via ingress replication (via MP2P tunnels) or LSM Multi-vendor solutions Cisco leader in industry standardization efforts

Cisco Live 2017 7/1/2018 Ethernet VPN Highlights PE1 PE2 PE3 PE4 CE1 C-MAC:M1 CE3 C-MAC:M3 VID 100 SMAC: M1 DMAC: F.F.F BGP MAC adv. Route EVPN NLRI MAC M1 via PE1 Data-plane address learning from Access Control-plane address advertisement / learning over Core Next generation solution for Ethernet multipoint (E-LAN) services PEs run Multi-Protocol BGP to advertise & learn Customer MAC addresses (C- MACs) over Core Same operational principles of L3VPN Learning on PE Access Circuits via data- plane transparent learning No pseudowire full-mesh required Unicast: use MP2P tunnels Multicast: use ingress replication over MP2P tunnels or use LSM Standardized at IETF – RFC 7432

Next-Generation Solutions for L2/L3VPN Solving VPLS challenges for per-flow Redundancy
Existing VPLS solutions do not offer an All- Active per-flow redundancy Looping of Traffic Flooded from PE Duplicate Frames from Floods from the Core MAC Flip-Flopping over Pseudowire E.g. Port-Channel Load-Balancing does not produce a consistent hash-value for a frame with the same source MAC (e.g. non MAC based Hash-Schemes) CE1 Echo ! M1 M2 PE1 PE2 PE3 PE4 CE2 Duplicate ! CE1 M1 M2 PE1 PE2 PE3 PE4 CE2 CE1 M1 M2 PE1 PE2 PE3 PE4 CE2 MAC Flip-Flop

EVPN - Components L2 and L3 in the same instance! EVPN Instance (EVI)
Cisco Live 2017 EVPN - Components 7/1/2018 L2 and L3 in the same instance! EVPN Instance (EVI) EVI spans all PEs participating in an EVPN MAC-VRF: A VRF table for MACs on a PE Encompass one or more bridge-domains, depending on service interface type Port-based VLAN-based (shown above) VLAN-bundling VLAN aware bundling (NEW) Ethernet Segment Represents a ‘site’ connected to one or more PEs Uniquely identified by a 10-byte global Ethernet Segment Identifier (ESI) Could be a single device or an entire network Single-Homed Device (SHD) Multi-Homed Device (MHD) Single-Homed Network (SHN) Multi-Homed Network (MHN) BGP Routes EVPN and PBB-EVPN define a single new BGP NLRI used to carry all EVPN routes NLRI has a new SAFI (70) Routes serve control plane purposes, including: MAC / IP address reachability MAC mass withdrawal Split-Horizon label adv. Aliasing Multicast endpoint discovery Redundancy group discovery Designated forwarder election BGP Route Attributes New BGP extended communities defined Expand information carried in BGP routes, including: MAC address moves C-MAC flush notification Redundancy mode MAC / IP bindings of a GW Split-horizon label encoding SHD Route Types [1] Ethernet Auto-Discovery (AD) Route [2] MAC Advertisement Route [3] Inclusive Multicast Route [4] Ethernet Segment Route (5) IP Prefix Advertisement Route Extended Communities ESI MPLS Label ES-Import MAC Mobility Default Gateway Router’s MAC PE BD MAC VRF CE1 ESI1 PE1 MHD CE2 ESI2 PE2

EVPN VPWS Benefits of EVPN applied to point-to-point services
Cisco Live 2015 EVPN VPWS Control-plane attachment circuit advertisement over the Core Benefits of EVPN applied to point-to-point services No signaling of PWs. Instead signals MP2P LSPs instead (ala L3VPN) All-active CE multi-homing (per-flow LB) Single-active CE multi-homing (per-service LB) Relies on a sub-set of EVPN routes to advertise Ethernet Segment and AC reachability PE discovery & signaling via a single protocol – BGP Per-EVI Ethernet Auto-Discovery route Handles double-sided provisioning with remote PE auto- discovery VPWS Service Config: EVI = 100 Local AC ID = AC2 Remote AC ID = AC1 MPLS ES1 PE2 CE1 CE2 ES2 VPWS Service Config: EVI = 100 Local AC ID = AC1 Remote AC ID = AC2 ES1 I have a P2P service that needs to communicate with the PE(s) that own of AC = AC2 BGP Eth. Auto-Discovery Route EVPN NLRI AC AC1 via PE1 Inherent inter-AS capability w/o the need for complex stitching (as was the case for PW) Ease of integration with EVPN and IP-VPN

EVPN Ethernet access Single/Dual Homed Solution, Legacy L2 access
PE1 PE1 A1 PE1 LACP STP/REP/ G.8032…. MPLS Core A1 MPLS Core MPLS Core A1 PE2 PE2 A1 PE2 A2 Ethernet EVPN-MPLS Ethernet EVPN-MPLS EVPN-MPLS

EVPN Seamless integration VPLS, VPWS, Ethernet
LACP VPWS CE B1 VM Leaf DCI DCI Spine VM Leaf MPLS Core Spine DCI DCI VM Leaf EVPN - VXLAN EVPN - MPLS A1 A2 VPLS

Symmetric Anycast IRB Routing and Bridging in the same instance
All-Active Multi-homed Access WITHOUT: mLAG (mLACP) VSS/vPCE… DCI DCI DC Fabric - MPLS/VXLAN L3 : RT2 [MAC/IP] - host-route RT5: [prefix] L2: RT2 [MAC/IP] L2: RT2 [MAC/IP] Leaf Leaf Leaf Anycast IRB Anycast IRB VM VM VM

NSO Main Features Logically centralized network services
Cisco Live 2017 7/1/2018 NSO Main Features Network Element Drivers (NEDs) Service Manager Device Manager Physical Networks Virtual Networks VNFM Controller Apps EMS and NMS Network Apps Service Model DeviceModel Applications REST, NETCONF, Java, Python, Erlang, CLI, Web UI NETCONF, REST, SNMP, CLI, etc Engineers Logically centralized network services Data models for data structures Structured representations of: Service instances Network configuration and state Mapping service operations to network configuration changes Transactional integrity Multiprotocol and multivendor support

Cisco Metro Fabric Design Benefits
Simple, scalable and automatable design End-to-End unified forwarding plane based on Segment Routing Less than 50ms convergence with TI-LFA based protection Full path programmability with guaranteed SLAs Flexible service/ workload placement Improved operational efficiency with a simplified protocol stack and modern tooling for automation Programmability and analytics with YANG data models and Telemetry

SRv6 VPN and TE on NCS 5500 Jiri Chaloupka - Technical Marketing Engineer Jisu Bhattacharya - Principal Engineer John Bettink - Distinguished Engineer Clarence Filsfils - Cisco Fellow

Stay Up-To-Date http://www.segment-routing.net/

Jiri Chaloupka - Technical Marketing Engineer

Similar presentations

Presentation on theme: "Jiri Chaloupka - Technical Marketing Engineer"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Jiri Chaloupka - Technical Marketing Engineer

Similar presentations

Presentation on theme: "Jiri Chaloupka - Technical Marketing Engineer"— Presentation transcript:

Similar presentations

About project

Feedback