Migrating to MPLS

Not just another MPLS talk – I promise!

Humberto Galiza – Network Engineer

Disclaimer

Opinions expressed are solely my own and do not express the views, opinions, products or
technologies of my current employer.

This presentation is intended for educational purposes only and do not replace independent
professional judgment.

The information being shared in the presentation haven’t hammered any NDAs. All the
references mentioned are public information and can be found on the Internet or as form of
Academic Papers and/or IETF Request For Comments (RFCs).
What to expect?

What this talk is What this talk is NOT:

• Overview of possible MPLS use cases for • MPLS design workshop
metro, campus, datacenter, etc.
• MPLS in depth
• MPLS tools as they apply to those use
• Configs details
cases
• Assumes you have some familiarity with
IPv4/IPv6 and MPLS fundamentals

Warning: Information overload

o There’s a lot to say about MPLS and TE
o But we only have ~25 min – It’s going to be
fast and furious!
o Just a taster and lots of pointers
o If I leave out your favourite protocol (or
vendor pet), please forgive me :p
Who am I?

• I’m a nice guy - (my wife used to say whenever she wants to shop
some stuff online at amazon.com) J
• Ex UFBA alumni (BSc Computer Science, 2009)
• Ex PoP-BA/RNP/AmLight staff
• Couple of years dealing with networks of different
sizes and complexity levels
• NDE @ AWS Global BB-Eng Team (Dublin, IE)
• Breaking & fixing super cool/massive-scale stuff :D
Problem statement

Layer-2 only networks

• Single failure/broadcast domain, slow convergence, network loops, etc.
• Single tasks like VLAN provisioning can become a nightmare in bigger/complex topologies
• Adding redundancy to an extended Ethernet network typically means relying on STP to keep
the topology loop free
• Troubleshooting can be tricky when dealing with complex topologies (multi-rings, metro
networks, campus networks, etc.)

Source: remessa.pop-ba.rnp.br
Source: www.cisco.com
MPLS migration: why we need it?

• Business perspective • Technical perspective

o Reduce costs (CAPEX), by consolidating a o Need for network segmentation (users,
single network for multiple Layer-2/3 applications, etc.)
services
o Need for easier configuration of site-to-site
o Support increasingly stringent SLAs and external WAN connectivity

o Handle increasing scale/complexity of o Need to sleep in peace, without having to

IP/non-IP based services worry about L2-loops, link flaps/failures (and
hence, users calling you in the middle of the
night ;-) )
MPLS recap in one slide: basic building blocks

• Network Infrastructure
o MPLS-enabled network devices: Label
Switched Routers (LSR)

• Core MPLS
o Label Switched Path (LSP)
o Forwarding Equivalence Class (FEC)
o Control Plane
• Label assignment & distribution
• LDP, RSVP, BGP, etc
o Forwarding Plane
• Label operations: push, swap, pop

• Other related protocols and protocols to

exchange information
o Between MPLS-enabled services
A day in the life of a MPLS packet

• It’s all about labels

o More than one label can be used for MPLS
packet encapsulation
• Each label in stack used for different
purposes
• Outer label always user for switching
MPLS packets in network
• Remaining inner labels used to specific
services/FECs, etc.
o MTU size is important!!!

• Allows building services such as

o MPLS VPNs: LDP + VPN label
o Traffic Engineering (FRR): LDP + TE label
o VPNs over TE core: LDP + TE + VPN label
o Any transport over MPLS: LDP + PW label
5 MPLS migration challenges

• As in any other migration there are challenges which needs to be

addressed. Here I came up with 5 (as the magical number J )
1. Mindset change
2. Traffic Engineering
3. Scaling the MPLS network
4. Maximizing the MPLS network utilization and efficiency
5. MPLS in the SDN era
 MPLS migration: challenge #1

Mindset change
• Your “VLAN pet” is dead - I know you will miss STP/EAPS/REP, etc J
o Start thinking now about services traversing the network, rather than VLANs.
o L3 p2p links between devices
o IGP + (labelling protocol) are now your best friends
• Loopback reachability/label mapping distribution across the MPLS network
• LDP is the easiest way to start – but may not be the best (see next slides)

B
MPLS migration: challenge #1 [cont]

Mindset change
• Welcome to the (wonderful) VPN world
o L2VPN (p2p: VPWS & p2mp: VPLS) – (a.k.a L2 Virtual-Circuit, EoMPLS, etc. depending on your vendor)
• LDP signalled: easy to configure, but may not scale in large/complex scenarios (high number of pw’s)
• BGP signalled (VPLS only): more complex, has nice features such as PE autodiscovery, etc.
• Ethernet VPN: next-generation L2VPN (RFC 7432) - use BGP to learn mac-address
o L3VPN
• MP-BGP, CsC, etc.
A

B
C
MPLS migration: challenge #2

Network vs Traffic Engineering

• Network Engineering
• Build your network to carry your predicted traffic
• Traffic Engineering
• Manipulate your traffic to fit your network

What is the point here?

• Traffic patterns are impossible to accurately predict
• Symmetric bandwidths/topologies, asymmetric load
• IP forwards based on destination IP address
• This can sometimes not be granular enough, and cause unequal network load
• This can cause temporary routing loops during network failure
MPLS migration: challenge #2 [cont]

The classical “fish” problem How MPLS TE solves the problem?

• IP (mostly) uses Destination-Based • Router A sees all links
Least-Cost Routing
• Router A computes paths on properties
• Alternate path under utilized other than just shortest cost; and create 2
tunnels
• Links Oversubscription / Network
congestion è massive packet drops!! • No link oversubscribed
o Also an issue on LDP-based MPLS
networks
MPLS migration: challenge #2 [cont]

What is MPLS TE? MPLS FastReRoute (FRR)

• Enhanced network availability, utilization, • This is one of the beauties of
and performance. Traffic Engineering with MPLS
• RSVP-TE: a signalling protocol to setup • Admin-groups, SRLGs, etc.
MPLS LSPs
• Widely deployed
• Enables
• Traffic Engineering
• Bandwidth Accounting
• Fast failure protection (<50ms)
MPLS migration: challenge #3

Scaling the MPLS network

• Configuration/automation
• Increase in network-size has led to
increased LSP scale

• Scale magnifies operational issues

• N2 LSPs between N routers problem
• The overhead of maintaining control-plane
state – in the entire network, and per LSR

• Monitoring at scale
Source: Leonardo Furtado/BPF – wiki.brasilpeeringforum.org
• What events are happening on the LSPs?
• Which ones needs operator attention?
• What properties of the LSPs are changing?
MPLS migration: challenge #3 [cont]

Scaling the MPLS network [cont]

• Large LSPs can’t fit small pipes
o How big of an LSP to set up?
o A single big LSP or several small ones?
• If the goal is to maximize link
utilization, smaller LSPs are better
o Fork more parallel LSPs

• Auto-bandwidth issues
o AutoBW: Automates the process of
monitoring and online adjustment of LSP
bandwidth
• No all vendors implement it correctly
L
o How to improve “appropriateness” of
resizing of the LSPs?
MPLS migration: challenge #4 [cont]

Maximizing the MPLS network • In the IETF, they worked on solutions in

utilization order to fix this issue:
• Per-flow load-balancing model: Traffic o Entropy Label, RFC 6790
polarization • L2VPN/L3VPN
o LAG/LACP ports • All LSRs must support it L
• if the hashing algorithm is not o Flow-Aware Transport (FAT) Label (or
efficient all the flows will pass FAT-PW), RFC 6391
through the same member of the • Easy to deploy (only on PEs), but L2VPN
LAG only
o ECMP (Equal-Cost Multi-Path) groups can
be affected too!
MPLS migration: challenge #4 [cont]

Maximizing the MPLS network

utilization [cont]
• How to load-share traffic towards remote
BGP next-hops/PEs using all LSPs as part
of an ECMP group?
o “In JunOS if no specific metric is
configured, an LSP attempts to track the
IGP metric toward the same destination
(the "to address" within the LSP
configuration).” [1]
o In short: only RSVP LSPs signalled over
the best/short IGP path will be used to
carry traffic (metric inheritance)
• LSPs in idle state
• LSP traffic polarization
o Possible solution: LSP metric manipulation

[1] https://www.juniper.net/documentation/en_US/junos/topics/topic-map/basic-lsp-configurtion.html#id-10233
MPLS migration: challenge #5

MPLS in the SDN era :p Key MPLS applications in the SDN era
• OpenFlow did not replace MPLS • Centralized Traffic Engineering
• MPLS and SDN are not competing o Topology discovery
technologies: MPLS is a key SDN • BGP, ISIS, OSPF, PCEP, etc
enabler. o Path computation
• Segment Routing (SR) seems to be a • Path computation algorithms
strong candidate to replace RSVP-TE o Path installation
o Maximum SID depth hardware/software • PCEP, SR-TE, Netconf, etc.
limitations
o OpenSource options:
• ONOS
• OpenDayLight
o Some proprietary options:
• Juniper Northstar controller
• Cisco Open SDN controller

Available at: https://www.amazon.com

Summary and Key takeaways

• MPLS is a mature technology with • Key applications of MPLS is to

widespread deployments implement VPN services
o Suitable both for SP and enterprise o Secure and scalable layer 2 and 3 VPN
networks connectivity
o Two types of MPLS users
• Indirect (subscriber): MPLS used as
transport for subscribed service
• MPLS supports advanced traffic
engineering capabilities
• Direct (DIY): MPLS implement in o QoS, bandwidth control, and failure
(own) SP or Enterprise network protection

• It’s all about labels… • MPLS & SDN are your good friends too!
o Label-based forwarding and IP protocol
extensions for label exchange
o Best of both worlds… L2-type forwarding
and L3 control plane
o Mind about MTU size (jumbro frame is
your friend)
Send questions, comments, and complaints to:
humbertogaliza [at] gmail [dot] com

Thanks for your patience!