IP addressing overloads location and identity – leading to Internet scaling issues
Why current IP semantics cause scaling issues?− Overloaded IP address semantic makes efficient
routing impossible
− Today, “addressing follows topology,” which limits route aggregation compactness
− IPv6 does not fix this
Why are route scaling issues bad?− Routers require expensive memory to hold
Internet Routing Table in forwarding plane
− It’s expensive for network builders/operators
− Replacing equipment for the wrong reason (to hold the routing table); replacement should be to implement new features
“… routing scalability is the most important problem facing the Internet today and must be solved … ”
Internet Architecture Board (IAB)October 2006 Workshop (written as RFC 4984)
LISP Overview
LISP creates a Level of indirection with two namespaces: EID and RLOC
EID (Endpoint Identifier) is the IP address of a host – just as it is today
RLOC (Routing Locator) is the IP address of the LISP router for the host
EID-to-RLOC mapping is the distributed architecture that maps EIDs to RLOCs
Analogous to a DNS Lookup
Network-based solution No host changes Minimal configuration Incrementally deployable
Support for mobility Address Family agnostic Uses Pull vs. Push Routing Open Standard
Prefix Next-hopw.x.y.1 e.f.g.hx.y.w.2 e.f.g.hz.q.r.5 e.f.g.hz.q.r.5 e.f.g.h
Non-LISP
RLOC Space
EID-to-RLOC
mapping
xTR
EID SpacexTR
EID RLOCa.a.a.0/24 w.x.y.1 b.b.b.0/24 x.y.w.2 c.c.c.0/24 z.q.r.5 d.d.0.0/16 z.q.r.5
MS/MR
PxTR
xTR
EID RLOCa.a.a.0/24 w.x.y.1 b.b.b.0/24 x.y.w.2 c.c.c.0/24 z.q.r.5 d.d.0.0/16 z.q.r.5
EID RLOCa.a.a.0/24 w.x.y.1 b.b.b.0/24 x.y.w.2 c.c.c.0/24 z.q.r.5 d.d.0.0/16 z.q.r.5
EID Space
LISP Overview
NJEDge.Net Overview
NJ’s Research and Education Network Since 2000
NJEDge.Net LISP Deployment
• LISP Briefing (June 2011)• CPOC (Aug 2011)• Deploy and Test LISP in Production
Environment• First LISP-Production Member (December
2011)
NJEdge LISP Architecture
v4/v6 Core
I2
Internet
Internet
Internet
Internet
Member
MS/MR/PxTR
PHL
NWKMS/MR/PxTR
Internet
Transition #1
Member peered with NJEDge and Provider X via BGP
Tuning BGP to properly balance Ingress Traffic Flows was Challenging Member owned 16
x /24s
Member
Internet
NJEDgeProvider X
Transition #1 Configure Member for
LISP Remove BGP Add Two Default
routes Proxy Router attracts
Ingress Traffic destined to Member and load balances towards the member.
Member
NJEDgeProvider X
xTR
PxTR
Announce Member
Address via BGPInterne
t
Benefits:• No BGP Configuration to Manage• Guaranteed Ingress Traffic Load Balancing
Transition #2
Local, Non-Member Member peers with Provider X & Y via BGP
Tuning BGP to properly balance Ingress Traffic Flows was Challenging Non-Member
Provider X Provider Y
Internet
NJEDge
Transition #2 Configure Member for
LISP; remove BGP and add two Default routes (one per provider)
Proxy Router attracts Ingress Traffic destined to Member and load balances across both of the Member’s Router interfaces. Non-Member
Provider X Provider Y
Internet
NJEDge
xTR
PxTR
Announce Member
Address via BGP
Transition #3 Post-Transition,
Member had budget to upgrade elderly Edge Router
Since LISP only “pulls” routing information, smaller memory requirements allow for inexpensive future router purchase.
Member
Internet
NJEDgeProvider X
xTR
PxTR
Map Resolution
Transition #3
Savings: ~$11K
Original Budget: $28K (estimated)
Alternative: $17K
(estimated)Assume
Hardware Life: 5-7
years
Next Steps
• Waitlist of 12 Members to be transitioned• Use LISP VM-Mobility to solve Disaster
Recovery initiatives.
LISP VM-Mobility
IP Network
WestDC
LISP Site
Legacy Site
Legacy Site
Legacy Site
East DC
PxTR
MappingDB
Data Center 1
Data Center 2
a.b.c.1VM
a.b.c.1VM
VM move
LISProuters
LISProuters
Internet
Multi-Tenant Compute
Multi-Tenant Network
LISP Updates VM-Move Across Subnets