Luigi IANNONE - Luigi is currently an Associate Professor at Telecom ParisTech (Paris), since May 2012. He was previously Senior Research Scientist at Deutsche Telekom Innovation Laboratories (TLabs, Berlin Germany); post-doc Researcher at Université catholique de Louvain (UCL - Belgium); and worked at the Université Pierre et Marie Curie (Paris VI – France), first as Ph.D. candidate and later as post-doc. His current research interests include intra- and inter- domain routing, future Internet architectures, as well as mobility, wireless networks, and wired/wireless convergence. He is currently serving on the editorial board of Elsevier Computer Networks Journal. Luigi Iannone is also co-chair of the LISP Working Group at the IETF (Internet Engineering Task Force) and the main developer of the OpenLISP Project. Wenqin Shao – Wenqin SHAO is a PhD candidate at Telecom ParisTech. Meanwhile he is also a research engineer working for BORDER 6. He received an Engineering degree from Telecom ParisTech in 2013 and a Bachelor of Engineering in 2010 from Fudan University, Shanghai. He previously worked as solution manager and network architect separately for SFR and Wibox, both of which are French telecom operators. His current research interests cover internet routing and traffic engineering, and more generally enhanced solutions for operating network systems, so as to deliver ever-evolving services in a less constrained Internet. Abstract: “LISP (locator/Identifier Separation Protocol) brings a revolutionary model for routing in largescale networks. Its original aim is to help reducing the size of the routing tables and thus bringing better scalability to the Internet. Due to its inherent flexibility, there are today several scenarios and use-cases where LISP is experimented and deployed either to enable new features or to fix (or at least alleviate) issues with current models and protocols (e.g., VM mobility, IPv6 transition, traffic-engineering, etc.). These new and improved capabilities are experimented within two co-existing environments: the LISP Beta-Network (http://www.lisp4.net), where Cisco is a major contributor, and LISP-lab (http://www.lisplab. org), mainly built on the open-source OpenLISP Project (http://www.openlisp.org). Within this session, we propose to present a case study where LISP is used as a control-plane signaling protocol for traffic engineering over the Internet. It intends to showcase how the current Internet performance can be improved through coordinated traffic engineering via orchestrated source and destination Autonomous Systems routing decisions. Such an objective is achieved without touching or tweaking in any way the current BGP routing infrastructure. In the proposed deployment model LISP provides both control- and data- plane functions; with a full LISP stack on both ends, it can as well operate as an traffic engineering control-plane on top of the BGP routing infrastructure.

1. Internet Traffic
Engineering with LISP
Wenqin Shao & Luigi Iannone
[wenqin.shao, luigi.iannone]@telecom-paristech.fr
!
!
PLNOG
September 2014

2. Roadmap
• Why we need more than BGP for TE?
• Why is LISP the answer?
• What is LISP?
• LISP & TE

3. Sub-optimal Inbound Path (I)
3
data from

4. Sub-optimal Inbound Path (II)
for this specific remote AS
80ms performance drop
!
!
for this local AS
314.6GB inbound traffic
54% of total inbound traffic
in 24h
4

5. Sub-optimal Inbound Path (III)
Min Transit (ms)
5

6. Sub-optimal Inbound Path (IV)
6

7. Sub-optimal Inbound Path (V)
!
!
Selective announcement
!
• stop announcing local prefixes to transit A
!
• advertise more specific local prefixes to transit B
!
connectivity risk
not granular enough
all inbound traffic impacted
7
/20
[/21,/21]

8. Sub-optimal Inbound Path (VI)
!
!
AS prepending w/o BGP community
!
•prepend local AS’s ASN several times
when announcing routes to transit A
!
!
•add BGP communities that make transit A prepend
its ASN several times when announcing local AS’s
prefixes to certain upstream AS where locates
the target remote AS
can’t override local preference setting
unpredictable results
8

9. Need for Inbound Load Balancing (I)
9 data from

10. Need for Inbound Load Balancing (II)
Real time traffic rate
> CDR
possibility of losing guaranteed service quality
> Interface rate
certainty of packet loss
!
95th percentile traffic rate
> CDR
extra billing
if you don’t know how to balance the load,
you pay more for bad service
10

11. Need for Inbound Load Balancing (III)
!
!
Selective announcement
!
• stop announcing local prefixes to transit A
!
• advertise more specific local prefixes to transit B
!
not granular enough
possibility of saturating Transit B if overdo
11

12. Need for Inbound Load Balancing (IV)
!
!
AS prepending w/o BGP community
!
•prepend local AS’s ASN several times
when announcing routes to transit A
!
!
•add BGP communities that make transit A prepend
its ASN several times when announcing local AS’s
prefixes to some upstream ASes
real data speaks
not effective
can’t override local preference setting
12

13. Does BGP have a limit?
(aka from where LISP comes from……)
600000
500000
400000
300000
200000
100000
0
DotCom Bubble
Growth Fear!!!
88 89 90 91 92 93 94 95 96 97 98 99 00 01 02 03 04 05 06 07 08 09 10 11 12 13
http://bgp.potaroo.net/as2.0/bgp-
Commercial Internet
CIDR
2008’s Economic Backdrop
IPv4
IPv6
13

14. Core/Edge Separation
(aka do we really need a unique routing/addressing space?)
85%
Who are all those prefixes?
• Number of Active ASes: 48349
• Number of Origin Only ASes: 41274 (85%)
• Average entries per Origin AS: ~11
• Roughly ~454 000 Prefixes are Stub
Networks
http://bgp.potaroo.net/as2.0/bgp-active.html
14

15. Packets in Core/Edge Separation
Internet
(DFZ)
ASs ASd
Core (Push Routing Model)
Edge (Pull Routing Model)
Payload
ASw
ASz ASk
ASj
Oracle
15

16. LISP
Locator/Id Separation Protocol
Internet
(DFZ)
Mapping
System
ASs ASd
Core (Push Routing Model)
Edge (Pull Routing Model)
Payload
ASw
ASz ASk
ASj
Oracle
Routing LOCator [RLOC] space (Push Routing Model)
Endpoint ID [EID] space (Pull Routing Model)
EIDs
EIDd
RLOC1
EID
d
RLOC2
EID
d
RLOC2EID
s
RLOC1EID
s
16

17. Internet
(DFZ)
ASw
ASz ASk
RLOC1EID
ASj
Mapping
System
EIDd-Pfx maps to:
!
RLOC1EID
s
d
ASs ASd
EIDd to
RLOC1EIDs
Routing LOCator [RLOC] space (Push Routing Model)
Endpoint ID [EID] space (Pull Routing Model)
EIDs
EIDd
RLOC1
EID
d
RLOC2
EID
d
RLOC2EID
s
RLOC2
EIDs to EIDd
Payload
Where is EIDd ?
R L O C 2
EID
d
LISP
Locator/Id Separation Protocol
17

18. Playing with Mappings
Just image the possibilities!
EIDd-Pfx maps to:
!
RLOC1EID
d
R L O C 2
EID
d
• What if mappings change dynamically based on:
• traffic volume
• policies
• path quality (e.g., delay, packet drops, etc)
• choose your metric…
18

19. LISP & Sub-optimal Inbound Path
Remote AS specific mapping
!
generate a EID-RLoC mapping
depending on the remote AS
19
EID-Pfx_X:
RLOC_B
EID-Pfx_X:
RLOC_B High
RLOC_A Low

20. LISP & Inbound TE Agility
EID-Pfx_X:
RLOC_B
EID-Pfx_X:
RLOC_B High
RLOC_A Low
EID-Pfx_X:
RLOC_A
EID-Pfx_X:
RLOC_A High
RLOC_B Low
Goup specific mapping
•identify groups •generate EID-RLoC mapping according to AS group
20

21. LISP & Inbound Load Balancing
EID-Pfx_X:
RLOC_B 50%
RLOC_A 50%
mapping entry is accompanied with LB weight
need equipment implementation support
21

22. We finally have the right tool!
(TE made easy)
• Presented use-cases will be tested on
• www.lisp-lab.org
In collaboration with
22