Presentation is loading. Please wait.

Presentation is loading. Please wait.

LISP Tech Talk - Part 3 Deployed Network and Use-Cases Dino Farinacci, Dave Meyer, Darrel Lewis, Vince Fuller, Gregg Schudel February 24, 2010.

Published byEarl Houston Modified over 8 years ago

Similar presentations

Presentation on theme: "LISP Tech Talk - Part 3 Deployed Network and Use-Cases Dino Farinacci, Dave Meyer, Darrel Lewis, Vince Fuller, Gregg Schudel February 24, 2010."— Presentation transcript:

1 LISP Tech Talk - Part 3 Deployed Network and Use-Cases Dino Farinacci, Dave Meyer, Darrel Lewis, Vince Fuller, Gregg Schudel February 24, 2010

2 LISP - Part 3LISP Google Tech TalkSlide 2 3-Part Series Tech Talk LISP Part 1 –Problem Statement, Architecture, and Protocol Design LISP Part 2 –Mapping Database Infrastructure and Interworking LISP Part 3 –Deployed Network and Use-Cases

3 LISP - Part 3LISP Google Tech TalkSlide 3 Agenda Summary of LISP Tech Talks Part 1 & Part 2 Describe LISP Test Network Describe Network Debugging Tools Pro-Bono Use-Case Enterprise Use-Cases (2) Service Provider Use-Case Data Center Use-Cases (3) LISP Mobile-Node Use-Case References

4 LISP - Part 3LISP Google Tech TalkSlide 4 Summary of Part 1

5 LISP - Part 3LISP Google Tech TalkSlide 5 Summary of Part 2

6 LISP - Part 3LISP Google Tech TalkSlide 6

7 LISP - Part 3LISP Google Tech TalkSlide 7

8 LISP - Part 3LISP Google Tech TalkSlide 8 Goals for LISP Network Experiments –Course Adjust Protocol Architecture Test Multiple Implementations Prove ALT Topology maps to EID Address Allocation Delegations Emulate MSP Business Models Protocol Learning Tool for Users Test bed for building Management Tools

9 LISP - Part 3LISP Google Tech TalkSlide 9

10 LISP - Part 3LISP Google Tech TalkSlide 10

11 LISP - Part 3LISP Google Tech TalkSlide 11

12 LISP - Part 3LISP Google Tech TalkSlide 12 When People Learn of LISP... What do customers say? –“I would like to make my enterprise core network simpler, I can do that by removing routes” –“I can allow client machines to roam and I can track them since EIDs never change” –“I can use either global or private addressing and not have to change them, I own my addresses, I have control” –“I would like to multi-home and use private addresses but it is so hard to do with NATs, I can do that now with LISP”

13 LISP - Part 3LISP Google Tech TalkSlide 13 When People Learn of LISP... What do customers say? –“I think I can use LISP on my PE routers and use BGP next-hops as my locators, my core can stay lean without MPLS” –“If I can modify LISP priority/weights I can use LISP for load-balancing traffic to servers” –“I can get IPv6 at my remote offices without upgrading my core network” –“I care about leaving a robust and scalable Internet when I retire, I want to be Internet Green”

14 LISP - Part 3LISP Google Tech TalkSlide 14 Pro-Bono Use-Case Pull your prefix from the core –The Internet Core –The Enterprise Core –People want to be Internet Green Use less resources in core Use less power in core The core is cheaper to operate Greener to deploy PI-based IPv6 –Since IPv6 EID-prefixes stay out of core

15 LISP - Part 3LISP Google Tech TalkSlide 15 Enterprise Use-Case 1: Low-Opex Multi-Homing Provider A 10.0.0.0/8 Provider B 11.0.0.0/8 S1S2 10.0.0.1 11.0.0.1 1.0.0.0/8 Active/active multi-homing –Low-Opex switchover (no BGP) More efficient bandwidth use by site –Use all the bandwidth you pay for New link revenue for ISP –At the benefit of keeping site’s routes out of their resources Decoupling addressing from ISP –Site has flexibility to change providers –Raises the bar for ISPs, better for consumer sites

16 LISP - Part 3LISP Google Tech TalkSlide 16 Enterprise Use-Case 2: Dynamic and Roaming VPNs San Francisco Los Angeles Boston New York 1.1.0.0/16 Engineering 1.2.0.0/16 Engineering Dallas 65.0.0.0/8 65.1.1.1 65.1.2.2 10.1.0.0/16 Marketing 10.2.0.0/16 Marketing 65.2.1.1 65.2.2.2 Marketing is using private addresses 65.3.1.1 Enterprise Core 65.3.2.2 65.4.1.1 65.4.2.2 1.2.0.0/16 -> (65.4.1.1, 65.4.2.2) 65.5.1.165.5.2.2 (65.5.1.1, 65.5.2.2) Engineering is using global PI addresses Core is using global PA addresses 1.2.0.0/16 Engineering An engineering site moves Dynamic creation of a site is done by simply registering EID-to-RLOC mapping to the Mapping Database System

17 LISP - Part 3LISP Google Tech TalkSlide 17 Service Provider Use-Case: Multiple Address Family Support The Internet core is not dual-stack, deal with it IPv6-only Site Dual Stack IPv6-only Site Dual Stack 2610:d0:1::/48 65.1.1.1 65.1.2.2 65.2.1.1 65.2.2.2 65.3.1.1 IPv4 Internet Core 65.3.2.2 65.4.1.1 65.4.2.2 LISP Site 2610:d0:2::/48 LISP Site 240.1.0.0/16 2610:d0:1::/48 Non-LISP Site 65.4.0.0/16 2001:1:2::/48 2001:1:2::1:1 2001:1:2::2:2 Dual-Stack ISP PxTR IPv6 path IPv4 path dino-unix.lisp6.net ipv6.google.com TCP-over-IPv6 Connection

18 LISP - Part 3LISP Google Tech TalkSlide 18 Service Provider Use-Case: Multiple Address Family Support A possible cable company –IPv6 core, can’t upgrade residential on IPv4 IPv4-only Residential Site IPv4-only Server Site 192.168.1.0/24 65.1.1.1 65.4.2.2 IPv6 Cable Core Network LISP Site 1.1.0.0/16 IPv4-only Server Site Non-LISP Site 65.4.0.0/16 65.4.1.1 65.1.2.2 65.3.1.1 65.3.2.2 IPv6 path IPv4 path Dual-Stack Region PxTR

19 LISP - Part 3LISP Google Tech TalkSlide 19 Data-Center Use-Case 1: Virtual Machine Mobility S1S3S2S4 RLOC A RLOC A ’ A’A’ A’A’ A A 1.1.1.254/24 1.1.11.254/24 1.1.1.1/24 1.1.11.2/24 2.2.2.254/24 2.2.22.254/24 2.2.2.3/24 2.2.22.4/24 1.1.0.0/16 -> A 2.2.0.0/16 -> A’ L3 Router LISP Router S1 moves Register to Map-Server 1.1.1.1/32 -> A’ Register to Map-Server for moved VM Data Center

20 LISP - Part 3LISP Google Tech TalkSlide 20 Data-Center Use-Case 2: Need 256-Wide ECMP?

21 LISP - Part 3LISP Google Tech TalkSlide 21 Data-Center Use-Case 3: Load Balance the SLBs Array of Servers Internet Data Center Array of SLBs L3 Router LISP Router Any brand Server Load Balancer Servers ETR ITR VIPs are EIDs VIPs EIDs -> RLOC-sets

22 LISP - Part 3LISP Google Tech TalkSlide 22 LISP Mobile Node Use-Case What if 2 mobile hand-sets could roam and keep a TCP connection established? What if 2 mobile hand-sets LISP encapsulated to each other with path stretch of 1? What if you could put up server functionality on your mobile hand-set? What if your hand-set could use all radios at the same time?

23 LISP - Part 3LISP Google Tech TalkSlide 23 EID-prefix: 2001:xxxx:yyyy::1/128 64.0.0.1 LISP Mobile Node Use-Case This is a LISP site! 65.0.0.1 Map-Server: 64.1.1.1 wifi 3G Can set ingress packet policy! Green x.x.x.x -> EID Red x.x.x.x -> Locator (RLOC)

24 LISP - Part 3LISP Google Tech TalkSlide 24 LISP Mobile Node Use-Case Run lightweight variant of LISP on the MN –draft-meyer-lisp-mn-01.txt EID can be burned into SIM card –Can be either an IPv4 or probably IPv6 address –Will be yours forever, your ‘network name’ Your DHCP address is the MN’s RLOC MN carries Map-Server RLOC while roaming When you get a new DHCP address: –Register new RLOC(s) to Map-Server(s) –Update ITR/PITR cachers

25 LISP - Part 3LISP Google Tech TalkSlide 25 LISP-MN: Can it Scale? Leave RLOCs alone, they map to underlying physical topology –There is absolutely no more specific state in the core for LISP MNs (or any other LISP site for that matter) More-specific state only in Map-Server –Map-Server is control-plane home agent –Map-Server already has covering route so no more specifics in the ALT Only other place for more specific state is in cachers (ITRs and PITRs) –How bad could this be?

26 LISP - Part 3LISP Google Tech TalkSlide 26 Back of the Envelope Calculation What if a map-cache entry was 1000 bytes? 1M entries in an ITR would cost you 1GB –A Google ITR would be a carrier class ITR, but 1GB isn’t much Let’s keep scaling up –Deploy 100 Google ITRs, you’re at 100M MNs –Ah, throw more memory at it, 10GB, you’re at 1B MNs 100 ITRs is not unreasonable since good user experience forces shortest exit, so an ITR can hold 10M phones Oh, by the way, 1000 bytes per entry is fairly fat! –Can optimize that easily This is achievable since granular state is only where you need it and no where else! Green: tracking EIDs or map-cache entries, Red: RLOC cost, Violet: memory cost

27 LISP - Part 3LISP Google Tech TalkSlide 27 Encouragement by the Following Peer Reviewers Vint Cerf –Father of the Internet and Google Chief Scientist Dave Clark –Luminary Internet Researcher from MIT Noel Chiappa –Locator/ID Separation Visionary and creator of NIMROD Paul Mockapetris –Inventor of DNS Len Bosack –Founder of cisco

28 LISP - Part 3LISP Google Tech TalkSlide 28 LISP Reference Material LISP Specs –draft-ietf-lisp-06.txt –draft-ietf-lisp-multicast-02.txt –draft-ietf-lisp-ms-03.txt –draft-ietf-lisp-alt-02.txt –draft-ietf-lisp-interwork-02.txt –draft-meyer-lisp-mn-01.txt –draft-farinacci-lisp-lig-02.txt URLs –http://www.lisp4.net –http://lisp4.cisco.com

Download ppt "LISP Tech Talk - Part 3 Deployed Network and Use-Cases Dino Farinacci, Dave Meyer, Darrel Lewis, Vince Fuller, Gregg Schudel February 24, 2010."

Similar presentations

LISP Mobile Node LISP Mobile Node draft-meyer-lisp-mn-00.txt Dino Farinacci, Vince Fuller, Darrel Lewis and David Meyer IETF StockholmHiroshima LISP Working.

LISP Mobile Node LISP Mobile Node draft-meyer-lisp-mn-00.txt Dino Farinacci, Vince Fuller, Darrel Lewis and David Meyer IETF StockholmHiroshima LISP Working.
© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 1 1 © 2010 Cisco and/or its affiliates. All rights reserved. LISP Mobility.

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 1 1 © 2010 Cisco and/or its affiliates. All rights reserved. LISP Mobility.
Why do current IP semantics cause scaling issues? −Today, “addressing follows topology,” which limits route aggregation compactness −Overloaded IP address.

Why do current IP semantics cause scaling issues? −Today, “addressing follows topology,” which limits route aggregation compactness −Overloaded IP address.
IPv4 - IPv6 Integration and Coexistence Strategies Warakorn Sae-Tang Network Specialist Professional Service Department A Subsidiary.

IPv4 - IPv6 Integration and Coexistence Strategies Warakorn Sae-Tang Network Specialist Professional Service Department A Subsidiary.
Transitioning to IPv6 April 15,2005 Presented By: Richard Moore PBS Enterprise Technology.

Transitioning to IPv6 April 15,2005 Presented By: Richard Moore PBS Enterprise Technology.
© 2006 Cisco Systems, Inc. All rights reserved.Cisco Public 1 Version 4.0 Implementing IP Addressing Services Accessing the WAN – Chapter 7.

© 2006 Cisco Systems, Inc. All rights reserved.Cisco Public 1 Version 4.0 Implementing IP Addressing Services Accessing the WAN – Chapter 7.
Project by: Palak Baid (pb2358) Gaurav Pandey (gip2103) Guided by: Jong Yul Kim.

Project by: Palak Baid (pb2358) Gaurav Pandey (gip2103) Guided by: Jong Yul Kim.
IETF 72 – July 2008 Vince Fuller, Darrel Lewis, Eliot Lear, Scott Brim, Dave Oran, Noel Chiappa, John Curran, Dino Farinacci, and David Meyer LISP Deployment.

IETF 72 – July 2008 Vince Fuller, Darrel Lewis, Eliot Lear, Scott Brim, Dave Oran, Noel Chiappa, John Curran, Dino Farinacci, and David Meyer LISP Deployment.
LISP-CONS A Mapping Database Service NANOG 41 David Meyer, Dino Farinacci, Vince Fuller, Darrel Lewis, Scott Brim, Noel Chiappa NANOG 41 October, 2007.

LISP-CONS A Mapping Database Service NANOG 41 David Meyer, Dino Farinacci, Vince Fuller, Darrel Lewis, Scott Brim, Noel Chiappa NANOG 41 October, 2007.
Guide to Network Defense and Countermeasures Second Edition

Guide to Network Defense and Countermeasures Second Edition
The Case for Enterprise Ready Virtual Private Clouds Timothy Wood, Alexandre Gerber *, K.K. Ramakrishnan *, Jacobus van der Merwe *, and Prashant Shenoy.

The Case for Enterprise Ready Virtual Private Clouds Timothy Wood, Alexandre Gerber *, K.K. Ramakrishnan *, Jacobus van der Merwe *, and Prashant Shenoy.
Internet Draft Status Internet Draft Status draft-farinacci-lisp-{00-12}.txt Dave Meyer, Vince Fuller, Darrel Lewis, Dino Farinacci IETF San Francisco.

Internet Draft Status Internet Draft Status draft-farinacci-lisp-{00-12}.txt Dave Meyer, Vince Fuller, Darrel Lewis, Dino Farinacci IETF San Francisco.
IPv4 and IPv6 Mobility Support Using MPLS and MP-BGP draft-berzin-malis-mpls-mobility-00 Oleg Berzin, Andy Malis {oleg.berzin,

IPv4 and IPv6 Mobility Support Using MPLS and MP-BGP draft-berzin-malis-mpls-mobility-00 Oleg Berzin, Andy Malis {oleg.berzin,
COM555: Mobile Technologies Location-Identifier Separation.

COM555: Mobile Technologies Location-Identifier Separation.
NANOG-46 Philadelphia, June 2009 Vince Fuller & Dave Meyer (for the rest of the LISP crew: Noel Chiappa, Dino Farinacci, Darrel Lewis, Andrew Partan, and.

NANOG-46 Philadelphia, June 2009 Vince Fuller & Dave Meyer (for the rest of the LISP crew: Noel Chiappa, Dino Farinacci, Darrel Lewis, Andrew Partan, and.
RIPE-59 Lisbon, October 2009 Vince Fuller (for the rest of the LISP crew: Noel Chiappa, Dino Farinacci, Darrel Lewis, Dave Meyer, Andrew Partan, and John.

RIPE-59 Lisbon, October 2009 Vince Fuller (for the rest of the LISP crew: Noel Chiappa, Dino Farinacci, Darrel Lewis, Dave Meyer, Andrew Partan, and John.
COS 461: Computer Networks

COS 461: Computer Networks
Lecture Week 7 Implementing IP Addressing Services.

Lecture Week 7 Implementing IP Addressing Services.
© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-1 Integrating Internet Access with MPLS VPNs Implementing Internet Access as a Separate VPN.

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—7-1 Integrating Internet Access with MPLS VPNs Implementing Internet Access as a Separate VPN.
LISP, SDN, and OpenDaylight

LISP, SDN, and OpenDaylight

Similar presentations

Ads by Google