NJEDge.Net LISP A rchitecture

1. NJEDge.Net LISP Architecture Jim Stankiewiczstank@njedge.net Michael Kowal mikowal@cisco.com

2. LISP Overview • 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 toimplement 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)

3. LISP Overview LISP creates a Level of indirection with two namespaces: EID and RLOC Prefix Next-hop w.x.y.1e.f.g.h x.y.w.2e.f.g.h z.q.r.5e.f.g.h z.q.r.5e.f.g.h • EID (Endpoint Identifier)is the IP address of a host – just as it is today EID Space • RLOC (Routing Locator)is the IP address of the LISP router for the host 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 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 Non-LISP MS/MR xTR PxTR xTR xTR EID-to-RLOC mapping • EID-to-RLOC mapping is the distributed architecture that maps EIDs to RLOCs • Analogous to a DNS Lookup RLOC Space EID Space • Network-based solution • No host changes • Minimal configuration • Incrementally deployable • Support for mobility • Address Family agnostic • Uses Pull vs. Push Routing • Open Standard

4. NJEDge.Net Overview NJ’s Research and Education Network Since 2000

6. NJEDge.Net LISP Deployment • LISP Briefing (June 2011) • CPOC (Aug 2011) • Deploy and Test LISP in Production Environment • First LISP-Production Member (December 2011)

7. NJEdge LISP Architecture Internet I2 Internet Internet Internet MS/MR/PxTR MS/MR/PxTR v4/v6 Core Internet NWK PHL Member

8. 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 Internet NJEDge Provider X Member

9. Transition #1 • Configure Member for LISP • Remove BGP • Add Two Default routes • Proxy Router attracts Ingress Traffic destined to Memberand load balances towards the member. Announce Member Address via BGP Internet PxTR xTR Provider X NJEDge Member • Benefits: • No BGP Configuration to Manage • Guaranteed Ingress Traffic Load Balancing

10. Transition #2 NJEDge • Local, Non-Member Member peers with Provider X & Y via BGP • Tuning BGP to properly balance Ingress Traffic Flows was Challenging Internet Provider X Provider Y Non-Member

11. Transition #2 NJEDge • 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. Announce Member Address via BGP PxTR Internet xTR Provider X Provider Y Non-Member

12. 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. Internet PxTR xTR NJEDge Provider X Member Map Resolution

13. Transition #3

14. Next Steps • Waitlist of 12 Members to be transitioned • Use LISP VM-Mobility to solve Disaster Recovery initiatives.

15. LISP VM-Mobility Legacy Site Legacy Site Legacy Site LISP Site IP Network West DC East DC PxTR Multi-Tenant Network Multi-Tenant Compute LISP Updates VM-Move Across Subnets Data Center 1 Data Center 2 Internet Mapping DB LISP routers LISP routers VM move VM VM a.b.c.1 a.b.c.1