Advanced Topics and Future Directions in MPLS

© 2011 Cisco and/or its affiliates. All rights reserved. Cisco Connect 11© 2012 Cisco and/or its affiliates. All rights reserved.
Toronto, Canada
May 30, 2013
Advanced Topics and
Future Directions in MPLS
Matt Gillies
Customer Solutions Architect

© 2012 Cisco and/or its affiliates. All rights reserved. Cisco Connect 2
Agenda
• IETF Update
• Unified MPLS
• Ethernet Virtual Private Network
• Segment Routing
• Summary
2

IETF update

Internet Engineering Task Force
• Responsible for MPLS standardization
• Six active working groups
MPLS
Layer 3 Virtual Private Networks (L3VPN)
Pseudowire Edge-to-Edge (PWE3)
Layer 2 Virtual Private Networks (L2VPN)
Common Control and Measurement Plane (CCAMP)
Path Computation Element (PCE)
4

MPLS Working Group
• Defined MPLS architecture and base protocols (LDP, RSVP-TE)
• Over 130 RFCs published to date
• Mature set of IP/MPLS specifications for both unicast and multicast
• Areas of focus
MPLS Transport Profile (MPLS-TP)
Seamless MPLS (building large scale, consolidated MPLS networks)
5

L2VPN WG
 Mature specifications for:
-Virtual Private Wire Service (VPWS): point-to-point L2 service
-Virtual Private LAN Service (VPLS): multipoint-to-multipoint Ethernet service
 New service definition:
- Virtual Private Multicast Service (VPMS): point-to-multipoint L2 service
 Areas of focus
-Enhancing VPLS - Ethernet VPN (E-VPN) and PBB Ethernet VPN (PBB-EVPN)
-Optimizing E-Tree support over VPLS
 No major RFC publications in recent past
6

IETF Summary
• Rich set of MPLS specifications covering
MPLS forwarding (unicast and multicast)
Layer-3 and layer-2 services (unicast and multicast)
• Current main focus areas:
Seamless MPLS
MPLS transport profile (MPLS-TP)
L2VPN enhancements (PBB-EVPN, VPMS)
Segment Routing ( ISIS WG )
7

Unified MPLS

Introduction
End-to-end, high-scale MPLS transport architecture for any service
 Simplifies end to end architecture by eliminating control and management plane
translations inherent in legacy designs (MPLS, Ethernet, IP, ATM, etc)
 Enables flexible placement of the L3 and L2 service termination
 Delivers a new level of scale for MPLS transport with RFC-3107 hierarchical labeled
BGP LSPs
 Provides simplified carrier class operations with end to end OAM, Performance
Monitoring and protection
9

Evolving MPLS Networks
10
MPLS
L2VPN
PW
L2VPN PE
L3VPN PE
L2VPN PE
L3VPN PE
EDGE EDGECOREAGGACCESS ACCESSAGG
L2 L2IP
IP L2+ IPL2 + IP
L2VPN PE
L3VPN PE L3VPN PE
L2VPN PE
MPLS
MPLS
IP IP IP
L3VPN PE L3VPN PE
L2VPN PE L2VPN PE

IP NGN Scaling – Number of Nodes
11
Transport
CPE / NT
100,000s–
1,000,000
Access
Nodes
10,000s–
100,000s
Distribution
Nodes
100s–1,000s
IP Edge
Nodes
10–100s
Core
Nodes
few–10s
Aggregation
Nodes
1,000s–
10,000s
As MPLS moves into aggregation and access
number of nodes increases sharply

Unified MPLS Requirements
• Minimize management touch points for service provisioning
• Minimize network state
• Flexibility in service termination
• High network availability (protection or fast restoration)
• End-to-end MPLS forwarding with a single routing domain
12
Access Access
MPLSMPLS
MPLS
Aggregation Core Aggregation
PE ABR ABR PE

Scale Challenges with Traditional MPLS Network Designs
• Building end-to-end LSPs between access devices requires flooding loopback prefixes
• IGP protocol would be required to support 100K prefixes
• Access devices would need to support 100K prefixes and 200K label (assuming two paths per
prefix)
• Prefix aggregation with LDP inter-area LSPs can only partially alleviate scale challenge
13
Access Access
MPLSMPLS
MPLS
PE ABR ABR PE

Hierarchal End-to-End LSP
• Hierarchical LSP approach with two transport labels (intra domain and inter domain)
Intra domain (IGP+LDP or RSVP-TE)
Inter domain (iBGP+label per RFC3107)
• No IP prefix redistribution between IGP domains
• Only access nodes and ABRs have reachability information for other access nodes
• BGP Inbound prefix filtering and Outbound Route Filtering (ORF) help reduce network state
14
Access Access
MPLSMPLS
MPLS
PE ABR ABR PE
Inter-domain
LSP
Intra-domain
LSP
Intra-domain
LSP
Intra-domain
LSP

Control Plane Operation (Pseudowire)
PE1 P ABR1 ABR2P P PE2
LDP /
RSVP-TE
iBGP
IP+Label
LDP /
RSVP-TE
LDP /
RSVP-TE
LDP /
RSVP-TE
LDP /
RSVP-TE
LDP /
RSVP-TE
iBGP
IP+Label
iBGP
IP+Label
T-LDP

Forwarding Plane Operation (Pseudowire)
PE1 P ABR1 ABR2P P PE2
Payload
Push
Push
Push
Pop PopPop
PW Label
BGP Label
IGP Label
Payload
PW Label
BGP Label
Payload
PW Label
BGP Label
IGP Label
Payload
PW Label
BGP Label
Payload
PW Label
IGP Label
Payload
PW Label
Payload Payload
Swap
Push
Pop
Push
Pop

Network Availability
17
• Restoration/protection for intra-domain LSP can rely on IGP Fast Convergence, IP
FRR or MPLS-TE FRR
• Restoration/protection for inter-domain (iBGP IP+Label) can use BGP Prefix
Independent Convergence
Access Access
MPLSMPLS
MPLS
PE ABR ABR PE
iBGP (IP+Label)
iBGP (IP+Label) iBGP (IP+Label)

Applicability and Deployment Considerations
• Unified MPLS benefits become more compelling as network scale increases
• Architecture leverages existing mechanisms (no major protocol extensions required)
• Architecture allows for numerous design variations (e.g. MPLS to access, MPLS to
aggregation, static labels, LDP DoD, etc.)
18

Ethernet VPN

Motivation for EVPN
• Technology evolution requirements
Multi-homing
Scale (MAC-addresses, Number of Service Instances)
Load balancing
Optimal Forwarding
Multicast optimization
Multi-tenancy
• Enhancements bring benefits to L2
services:
Business services
Mobile backhaul
Data center interconnect (DCI) solution
20
SP DC1 SP DC2
Ent DC1 Ent DC2
SP NGNDCPE
DCPE
DCE
DCE
PE PE
CE CE
Enterprise DCI “back door”
Standalone DCI network

• Next generation solution for Ethernet
multipoint connectivity services
• PEs run Multi-Protocol BGP to advertise
& learn MAC addresses over Core
• Learning on PE Access Circuits via
data-plane transparent learning
• No pseudowires
Unicast: use MP2P tunnels
Multicast: use ingress replication over MP2P
tunnels or use LSM
Full-Mesh of PW no longer required !!
• Under standardization at IETF – draft-
ietf-l2vpn-evpn
Ethernet VPN
Highlights
MPLS
PE1
CE1
PE2
PE3
CE3
PE4
VID 100
SMAC: M1
DMAC: F.F.F
BGP MAC adv. Route
E-VPN NLRI
MAC M1 via PE1
Data-plane address
learning from Access
Control-plane address
advertisement / learning
over Core

• Combines Ethernet Provider Backbone
Bridging (PBB - IEEE 802.1ah) with Ethernet
VPN
PEs perform as PBB Backbone Edge Bridge (BEB)
• Reduces number of BGP MAC advertisements
routes by aggregating Customer MACs (C-
MAC) via Provider Backbone MAC (B-MAC)
Addresses virtualized data centers with C-MAC count
into the millions
PEs advertise local Backbone MAC (B-MAC)
addresses in BGP
C-MAC and C-MAC to B-MAC mapping learned in
data-plane
• Under standardization at IETF – draft-ietf-
l2vpn-pbb-evpn
PBB Ethernet VPN
Highlights
MPLS
PE1
CE1
PE2
PE3
CE3
PE4
B-MAC:
B-M1 B-M2
B-M2
BGP MAC adv. Route
E-VPN NLRI
MAC B-M1 via PE2
B-MAC:
B-M1
Control-plane address
advertisement / learning
over Core (B-MAC)
Data-plane address
learning from Access
• Local C-MAC to local B-
MAC binding
Data-plane address
learning from Core
• Remote C-MAC to remote
B-MAC binding

• Active / Active Multi-Homing
with flow-based load
balancing in CE to PE
direction
Maximize bisectional bandwidth
Flows can be L2/L3/L4 or
combinations
• Flow-based load balancing in
PE to PE direction
Multiple RIB entries associated
for a given MAC
Exercises multiple links towards
CE
23
Solution Requirements
All-Active Redundancy and Load Balancing
P
E
P
E
P
E
P
E
Vlan X - F1
Vlan X –
F2
Flow Based Load-balancing – CE to PE direction
P
E
P
E
P
E
P
E
Flow Based Load-balancing – PE to PE direction
Vlan X - F1
Vlan X –
F2

• Optimal forwarding for unicast and
multicast
• Shortest path – no triangular forwarding
at steady-state
• Loop-Free & Echo-Free Forwarding
• Avoid duplicate delivery of flooded traffic
• Multiple multicast tunneling options:
Ingress Replication
P2MP LSM tunnels
MP2MP
24
Optimal Forwarding
PE1
PE2
PE3
PE4
CE1 CE2
Echo !
PE1
PE2
PE3
PE4
CE1 CE2 Duplicate !
CE1 CE2PE1
PE2
PE3
PE4Triangular
Forwarding!

• Server Virtualization fueling growth in MAC Address scalability:
1 VM = 1 MAC address.
1 server = 10’s or 100’s of VMs
• MAC address scalability most pronounced on Data Center WAN Edge for Layer 2
extensions over WAN.
Example from a live network: 1M MAC addresses in a single SP data center
MAC Address Scalability
25
WAN
DC Site 1
DC Site 2
DC Site N
1K’s
10K’s
1M’s
N * 1M

E-VPN / PBB-EVPN Concepts
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
• E-VPN and PBB-EVPN
define a single new BGP
NLRI used to carry all E-
VPN routes
• NLRI has a new SAFI (70)
• Routes serve control plane
purposes, including:
MAC address reachability
MAC mass withdrawal
Split-Horizon label adv.
Aliasing
Multicast endpoint discovery
Redundancy group discovery
Designated forwarder election
E-VPN Instance (EVI)
• EVI identifies a VPN in the
network
• Encompass one or more
bridge-domains,
depending on service
interface type
Port-based
VLAN-based (shown above)
VLAN-bundling
VLAN aware bundling (NEW)
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
PE
BD
BD
EVIEVI
PE1
PE2
CE1
CE
2
SHD
MHD
ESI1
ESI2
Route Types
[1] Ethernet Auto-Discovery (AD) Route
[2] MAC Advertisement Route
[3] Inclusive Multicast Route
[4] Ethernet Segment Route
Extended Communities
ESI MPLS Label
ES-Import
MAC Mobility
Default Gateway

Split Horizon
For Ethernet Segments – E-VPN
• PE advertises in BGP a split-horizon label (ESI MPLS Label) associated with
each multi-homed Ethernet Segment
• Split-horizon label is only used for multi-destination frames (Unknown
Unicast, Multicast & Broadcast)
• When an ingress PE floods multi-destination traffic, it encodes the Split-
Horizon label identifying the source Ethernet Segment in the packet
• Egress PEs use this label to perform selective split-horizon filtering over the
attachment circuit
PE1
PE2
PE3
PE4
CE1 CE3
ESI-1 ESI-2
CE4
CE5
Challenge:
How to prevent flooded traffic from echoing
back to a multi-homed Ethernet Segment?
Echo !

Split Horizon
For Ethernet Segments – PBB-EVPN
• PEs connected to the same MHD use the same B-MAC address for the
Ethernet Segment
1:1 mapping between B-MAC and ESI (for All-Active Redundancy with flow-based LB)
• Disposition PEs check the B-MAC source address for Split-Horizon filtering
Frame not allowed to egress on an Ethernet Segment whose B-MAC matches the B-
MAC source address in the PBB header
PE1
PE2
PE3
PE4
CE1 CE3
ESI-1 ESI-2
CE4
CE5
Challenge:
How to prevent flooded traffic from echoing
back to a multi-homed Ethernet Segment?
Echo !
B-MAC1
B-MAC1

Designated Forwarder (DF)
DF Election
• PEs connected to a multi-homed Ethernet Segment discover each other via BGP
• These PEs then elect among them a Designated Forwarder responsible for forwarding
flooded multi-destination frames to the multi-homed Segment
• DF Election granularity can be:
Multiple DFs for load-sharing
Per Ethernet Tag on Ethernet Segment (E-VPN)
Per I-SID on Ethernet Segment (PBB-EVPN)
PE1
PE2
PE3
PE4
CE1 CE2
ESI-1 ESI-2
Challenge:
How to prevent duplicate copies of flooded
traffic from being delivered to a multi-homed
Ethernet Segment? Duplicate !

Comparison of L2VPN Solutions
30
Requirement VPLS PBB-VPLS E-VPN PBB-EVPN
Multi-Homing with All-Active Forwarding
VLAN Based Load-balancing CE-to-PE ✔ ✔ ✔ ✔
Flow Based Load-balancing CE-to-PE x x ✔ ✔
Flow Based Load-balancing PE-to-PE x x ✔ ✔
Flow Based Multi-Pathing in the Core ✔ ✔ ✔ ✔
MAC Scalability
Scale to Millions of C-MAC Addresses x ✔ x ✔
Confinement of C-MAC entries to PE with active flows ✔ ✔ x ✔
MAC Summarization x x ✔ ✔
MAC Summarization co-existence with C-MAC Mobility x x x ✔
Flexible VPN Policies
Per C-MAC Forwarding Control Policies x x ✔ x
Per-Segment Forwarding Control Policies x x ✔ ✔

Summary
• E-VPN / PBB-EVPN are next-generation L2VPN solutions based on a BGP
control-plane for MAC distribution/learning over the core
• E-VPN / PBB-EVPN were designed to address following requirements:
–All-active Redundancy and Load Balancing
–Simplified Provisioning and Operation
–Optimal Forwarding
–Fast Convergence
• In addition, PBB-EVPN and its inherent MAC-in-MAC hierarchy provides:
–Scale to Millions of C-MAC (Virtual Machine) Addresses
–MAC summarization co-existence with C-MAC (VM) mobility
• E-VPN / PBB-EVPN applicability goes beyond DCI into Carrier Ethernet use
cases

Segment Routing

Key Takeaways
• Simple to deploy and operate
Leverage MPLS services & hardware
straightforward ISIS/OSPF extension
• Provide for optimum scalability, resiliency and virtualization
• Perfect integration with applications

Operators ask drastic LDP/RSVP improvement
• Simplicity
– less protocols to operate
– less protocol interactions to troubleshoot
– avoid directed LDP sessions between core routers
– deliver automated FRR for any topology
• Scale
– avoid millions of labels in LDP database
– avoid millions of TE LSP’s in the network
– avoid millions of tunnels to configure

Segment Routing Key Concepts
• Forwarding state (segment) is established by IGP
– LDP and RSVP-TE are not required
– Agnostic to forwarding dataplane: IPv6 or MPLS
• MPLS Dataplane is leveraged without any modification
– push, swap and pop: all what we need
– segment = label
• Source Routing
– source encodes path as a label or stack of segments
– two segments: node or adjacency

Adjacency Segments
• Nodes advertises adjacency label per link
– simple IGP extension
• Only advertising node installs adjacency segment in data plane
• Enables source routing along any explicit path (segment list)
B C
N O
Z
D
P
A
9101
9105
9107
9103
9105
9101
9105
9107
9103
9105
9105
9107
9103
9105
9107
9103
9105
9103
9105
9105

Node Segment
• Nodes advertise a node segment
– simple IGP extension
• All remote nodes install node segment ids in data plane
A packet injected anywhere
with top label 65 will reach Z
via IGP shortest path
A B C
Z
D
65
FEC Z
push 65
swap 65
to 65
swap 65
to 65 pop 65
Packet
to Z
Packet
to Z
65
Packet
to Z
65
Packet
to Z
65
Packet
to Z

Combining Segments
• Source Routing
• Any explicit path can be expressed: ABCOPZ
A B C
M N O
Z
D
P
Pop
9003
Packet to Z
65
9003
Packet to Z
65
Packet to Z
Packet to Z
65
Packet to Z
65
9003
72
Packet to Z
65
9003
72
72
72
65
65

ISIS automatically installs segments
• Simple extension
• Excellent Scale: a node installs N+A FIB entries
– N node segments and A adjacency segments
A B C
M N O
Z
D
P
Nodal segment to C
Nodal segment to Z
Adj Segment
Nodal segment to C

Automated & Guaranteed FRR
• IP-based FRR is guaranted in any
topology
– 2002, LFA FRR project at Cisco
– draft-bryant-ipfrr-tunnels-03.txt
• Directed LFA (DLFA) is guaranteed when
metrics are symetric
• No extra computation (RLFA)
• Simple repair stack
– node segment to P node
– adjacency segment from P to Q
Backbone
C1 C2
E1 E4
E3E2
1000
Node segment
to P node
Default metric: 10

Scalable TE and Segment Routing
• An SR core router scales much than with RSVP-TE
– The state is not in the router but in the packet
– N+A vs N^2
N: # of nodes in the network
A: # of adjacencies per node

MPLS Control and Forwarding Operation with Segment Routing
PE1 PE2
IGPPE1 PE2
Services
IPv4 IPv6
IPv4
VPN
IPv6
VPN
VPWS VPLS
Packet
Transport
LDP
MPLS Forwarding
RSVP BGP Static IS-IS OSPF
No changes to
control or
forwarding plane
IGP label
distribution, same
forwarding plane
BGP / LDP

Reality
• SR EFT is available!
– 12k, ASR9k, CRS1, CRS3
– get it to your lab
• Working aggressively with lead customers towards productization

IETF
• Simple ISIS/OSPF extension
• Welcoming contribution

Segment Routing
Use Cases

Application controls – network delivers
Path ABCOPZ is ok. I account the BW.
Then I steer the traffic on this path
FULL
66
65
68
Tunnel AZ onto
{66, 68, 65}
The network is simple, highly programmable and responsive to rapid changes
2G from A to Z please

Simple and Efficient Transport of MPLS services
• Efficient packet networks leverage ecmp-
aware shortest-path!
– node segment!
• Simplicity
– one less protocol to operate
– No complex LDP/ISIS synchronization to
troubleshoot
A B
M N
PE2PE1
All VPN services ride on the node segment
to PE2

Simple Disjointness
Non-Disjoint Traffic
A sends traffic with [65]
Classic ecmp “a la IP”
Disjoint Traffic
A sends traffic with [111, 65]
Packet gets attracted in blue plane and then
uses classic ecmp “a la IP”
SR avoids state in the core
SR avoids enumerating RSVP-TE
tunnels for each ECMP paths
ECMP-awareness!

CoS-based TE
• Tokyo to Brussels
– data: via US: cheap capacity
– VoIP: via Russia: low latency
• CoS-based TE with SR
– IGP metric set such as
> Tokyo to Russia: via Russia
> Tokyo to Brussels: via US
> Russia to Brussels: via Europe
– Anycast segment “Russia” advertised by Russia core routers
• Tokyo CoS-based policy
– Data and Brussels: push the node segment to Brussels
– VoIP and Brussels: push the anycast node to Russia, push
Brussels
Node segment to Brussels
Node segment to Russia

LFIB with Segment Routing
PE
PE
PE
PE
PE
PE
PE
PE
P
In Label Out Label
Out
Interface
L1 L1 Intf1
L2 L2 Intf1
… … …
L8 L8 Intf4
L9 Pop Intf2
L10 Pop Intf2
… … …
Ln Pop Intf5
Node
Segment
Ids
Adjacency
Segment
Ids
Forwarding
table remains
constant
• LFIB populated by IGP (ISIS / OSPF)
• Forwarding table remains constant
(Nodes + Adjacencies) regardless of
number of paths
• Other protocols (LDP, RSVP, BGP) can
still program LFIB

Segment Routing
Configuration

L3VPN Using Segment Routing
PE2PE1
VRF RED
192.168.255.1/32
VRF RED
192.168.255.2/32
IP/MPLS
(segment routing)

172.16.255.101/32
SID=16101
Topology
PE2
P1
P2
PE1
172.16.255.102/32
SID=16102
172.16.255.2/32
SID=16002
172.16.255.1/32
SID=16001

asr9000-pe1
!
router isis DEFAULT
is-type level-2-only
net 49.0000.1720.1625.5001.00
address-family ipv4 unicast
metric-style wide
!
interface Loopback0
passive
nodal-sid sid-value 16001
!
!
interface GigabitEthernet0/0/0/4
point-to-point
!
!
point-to-point
!
!
!
Edge Configuration (Node Segment Id)
Packets with label
16001 forwarded
towards PE1 via IS-IS
shortest path. PHP
enabled by default.
172.16.255.101/32
SID=16101
PE2
P1
P2
PE1
172.16.255.102/32
SID=16102
172.16.255.2/32
SID=16002
172.16.255.1/32
SID=16001

asr9000-p2
!
router isis DEFAULT
is-type level-2-only
net 49.0000.1720.1625.5102.00
metric-style wide
!
interface Loopback0
passive
nodal-sid sid-value 16102 PHP-disable
!
!
point-to-point
!
!
point-to-point
!
!
point-to-point
!
!
!
Core Configuration (Node Segment Id)
Packets with label
16102 forwarded
towards P2 via IS-IS
shortest path. PHP
disabled.
172.16.255.101/32
SID=16101
PE2
P1
P2
PE1
172.16.255.102/32
SID=16102
172.16.255.2/32
SID=16002
172.16.255.1/32
SID=16001

172.16.255.101/32
SID=16101
PE2
P1
P2
PE1
172.16.255.102/32
SID=16102
172.16.255.2/32
SID=16002
172.16.255.1/32
SID=16001
RP/0/RSP0/CPU0:asr9000-pe1#sh isis database detail verbose asr9000-pe2.00
Tue May 7 12:49:07.939 PDT
IS-IS DEFAULT (Level-2) Link State Database
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
asr9000-pe2.00-00 0x0000076b 0xe36c 1123 0/0/0
Area Address: 49.0000
NLPID: 0xcc
Hostname: asr9000-pe2
IP Address: 172.16.255.2
Metric: 10 IS-Extended asr9000-p2.00
Metric: 10 IP-Extended 172.16.0.0/31
Nodal-SID: 16002 PHP-off:1 Ext:0
Total Level-2 LSP count: 1 Local Level-2 LSP count: 0
RP/0/RSP0/CPU0:asr9000-pe1#
IS-IS Database Verification for Edge Node
(Node Segment Id)
Node segment id
associated with PE2
loopback

RP/0/RSP0/CPU0:asr9000-pe1#sh isis database detail verbose asr9000-p2.00
Tue May 7 12:54:57.779 PDT
IS-IS DEFAULT (Level-2) Link State Database
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
asr9000-p2.00-00 0x0000001a 0x39d4 1169 0/0/0
Area Address: 49.0000
NLPID: 0xcc
Hostname: asr9000-p2
IP Address: 172.16.255.102
Metric: 10 IS-Extended asr9000-pe2.00
Metric: 10 IS-Extended asr9000-pe1.00
Nodal-SID: 16102 PHP-off:1 Ext:0
Total Level-2 LSP count: 1 Local Level-2 LSP count: 0
IS-IS Database Verification for Core Node
(Node Segment Id)
172.16.255.101/32
SID=16101
PE2
P1
P2
PE1
172.16.255.102/32
SID=16102
172.16.255.2/32
SID=16002
172.16.255.1/32
SID=16001
Node segment id
associated with P2
loopback

RP/0/RSP0/CPU0:asr9000-pe1#sh mpls forwarding
Tue May 7 12:22:53.650 PDT
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
16001 Aggregate default: Per-VRF Aggr[V]
default 59
16002 16002 No ID Gi0/0/0/4 172.16.0.4 18722
16002 No ID Gi0/0/0/5 172.16.0.7 0
16020 Aggregate RED: Per-VRF Aggr[V]
RED 4500
16101 16101 No ID Gi0/0/0/5 172.16.0.7 0
16102 16102 No ID Gi0/0/0/4 172.16.0.4 0
Edge Forwarding Plane Verification (Node Segment Id)
Local node segment id
Node segment id to
reach PE1 via ECMP
Node segment id to
reach P1
Node segment id to
reach P2
172.16.255.101/32
SID=16101
PE2
P1
P2
PE1
172.16.255.102/32
SID=16102
172.16.255.2/32
SID=16002
172.16.255.1/32
SID=16001

RP/0/RSP0/CPU0:asr9000-p2#sh mpls forwarding
Tue May 7 13:17:35.480 PDT
Local Outgoing Prefix Outgoing Next Hop Bytes
Label Label or ID Interface Switched
------ ----------- ------------------ ------------ --------------- ------------
16001 Pop No ID Gi0/0/0/4 172.16.0.5 0
16002 16002 No ID Gi0/0/0/6 172.16.0.2 21258
16101 16101 No ID Gi0/0/0/5 172.16.0.8 0
RP/0/RSP0/CPU0:asr9000-p2#
Core Forwarding Plane Verification (Node Segment Id)
Node segment id to
reach PE1 (PHP)
Node segment id to
reach P1
Node segment id to
reach PE2
172.16.255.101/32
SID=16101
PE2
P1
P2
PE1
172.16.255.102/32
SID=16102
172.16.255.2/32
SID=16002
172.16.255.1/32
SID=16001

PE2PE1
VRF RED
192.168.255.1/32
VRF RED
192.168.255.2/32
IP/MPLS
(segment routing)
hostname asr9000-pe1
!
vrf RED
import route-target
65172:0
!
export route-target
65172:0
!
!
!
interface Loopback11
vrf RED
ipv4 address 192.168.255.1 255.255.255.255
!
router bgp 65172
!
address-family vpnv4 unicast
!
neighbor 172.16.255.2
remote-as 65172
update-source Loopback0
!
address-family vpnv4 unicast
!
!
vrf RED
rd 65172:0
redistribute connected
!
!
!
L3VPN Configuration (Node Segment Id)
L3VPN usual
configuration
172.16.255.1/32
SID=16001
172.16.255.2/32
SID=16002

RP/0/RSP0/CPU0:asr9000-pe1#sh bgp vpnv4 unicast labels
Tue May 7 13:21:11.106 PDT
BGP router identifier 172.16.255.1, local AS number 65172
BGP generic scan interval 60 secs
BGP table state: Active
Table ID: 0x0 RD version: 1269798720
BGP main routing table version 23
BGP scan interval 60 secs
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, r RIB-failure, S stale, N Nexthop-discard
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Rcvd Label Local Label
Route Distinguisher: 65172:0 (default for vrf RED)
*> 192.168.255.1/32 0.0.0.0 nolabel 16020
*>i192.168.255.2/32 172.16.255.2 16000 nolabel
Processed 2 prefixes, 2 paths
RP/0/RSP0/CPU0:asr9000-pe1#sh cef vrf RED 192.168.255.2
Tue May 7 13:20:58.960 PDT
192.168.255.2/32, version 15, internal 0x14004001 (ptr 0xad279764) [1], 0x0 (0x0), 0x410
(0xadf7a4b0)
Updated May 7 09:41:16.371
Prefix Len 32, traffic index 0, precedence n/a, priority 3
via 172.16.255.2, 3 dependencies, recursive [flags 0x6010]
path-idx 0 [0xae0429a8 0x0]
next hop VRF - 'default', table - 0xe0000000
next hop 172.16.255.2 via 16002/0/21
next hop 172.16.0.4/32 Gi0/0/0/4 labels imposed {16002 16000}
next hop 172.16.0.7/32 Gi0/0/0/5 labels imposed {16002 16000}
L3VPN Control and Forwarding Plane Verification
(Node Segment Id)
Label stack to
forward traffic to
192.168.255.2/32
(VRF RED) via
ECMP (as usual)
PE2PE1
VRF RED
192.168.255.1/32
VRF RED
192.168.255.2/32
IP/MPLS
(segment routing)
172.16.255.1/32
SID=16001
172.16.255.2/32
SID=16002
BGP local/remote
labels for VPNv4
prefixes (as usual)

Summary
• New MPLS enhancements focus on
Increased deployment scale (unified MPLS)
L2VPN (VPLS) efficiency and scaling (PBB-EVPN)
• Unified MPLS defines scalable (hierarchical) architecture to extend MPLS to
access/aggregation for an SP IP NGN
• PBB-EVPN defines BGP extensions to enhance scale and resiliency of existing VPLS
deployments and meet data centers requirements
• Segment Routing offers an elegant way to scale SP networks and support application
interaction with SDN’s
62

Complete Your Paper
“Session Evaluation”
Give us your feedback and you could win
1 of 2 fabulous prizes in a random draw.
Complete and return your paper
evaluation form to the room attendant
as you leave this session.
Winners will be announced today.
You must be present to win!
..visit them at BOOTH# 100

Thank you.

PBB-EVPN: A Closer Look
DF Election with VLAN Carving
Prevent duplicate delivery of flooded frames.
Uses BGP Ethernet Segment Route.
Non-DF ports are blocked for flooded traffic (multicast, broadcast,
unknown unicast).
Performed per Segment rather than per (VLAN, Segment).
Split Horizon for Ethernet Segment
Prevent looping of traffic originated from a multi-homed segment.
Performed based on B-MAC source address rather than ESI
MPLS Label.
Aliasing
PEs connected to the same multi-homed Ethernet Segment
advertise the same B-MAC address.
Remote PEs use these MAC Route advertisements for aliasing
load-balancing traffic destined to C-MACs reachable via a given
B-MAC.
65
PE PE
PE PE
PE PE
PE PE
PE PE
PE
B-MAC1
B-MAC1

PBB-EVPN: Dual Homed Device
• Each PE advertises a MAC route per Ethernet Segment (carries B-MAC associated with Ethernet Segment).
Both PEs advertise the same B-MAC for the same Ethernet Segment.
• Remote PE installs both next hops into FIB for associated B-MAC.
Hashing used to load-balance traffic among next hops.
• PE1 MAC Routes:
Route: RD11, B-MAC1, RT2, RT3
• PE2 MAC Routes:
Route: RD22, B-MAC1, RT2, RT3
66
VPN B-MAC NH
RT3 B-MAC1 PE1
RT3 B-MAC1 PE2
RT2 B-MAC1 PE1
RT2 B-MAC1 PE2
RIB
VPN B-MAC NH
RT3 B-MAC1 PE1, PE2
RT2 B-MAC1 PE1, PE2
FIB
PE1
PE2
VLAN 2, 3
VLAN 2,3
B-MAC1
PE3
MPLS/ IP

Advanced Topics and Future Directions in MPLS

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Advanced Topics and Future Directions in MPLS

Similar to Advanced Topics and Future Directions in MPLS (20)

More from Cisco Canada

More from Cisco Canada (20)

Recently uploaded

Recently uploaded (20)

Advanced Topics and Future Directions in MPLS