1 / 27

LISP BOF Update

LISP BOF Update. draft-farinacci-lisp-08.txt Dino Farinacci, Dave Meyer, Vince Fuller, Darrel Lewis, Scott Brim, Dave Oran IETF Dublin - July 2008. Agenda. Overview of LISP Changing Mapping Database Entries Support for Mixed Locators Spec changes between -06 to -08 Open Issues.

dale
Download Presentation

LISP BOF Update

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. LISP BOF Update draft-farinacci-lisp-08.txt Dino Farinacci, Dave Meyer, Vince Fuller, Darrel Lewis, Scott Brim, Dave Oran IETF Dublin - July 2008

  2. Agenda • Overview of LISP • Changing Mapping Database Entries • Support for Mixed Locators • Spec changes between -06 to -08 • Open Issues IETF Dublin - July 2008

  3. LISP Internet Drafts draft-farinacci-lisp-08.txt draft-fuller-lisp-alt-02.txt draft-lewis-lisp-interworking-01.txt draft-farinacci-lisp-multicast-00.txt draft-meyer-lisp-eid-block-01.txt draft-mathy-lisp-dht-00.txt draft-iannone-openlisp-implementation-01.txt draft-brim-lisp-analysis-00.txt draft-meyer-lisp-cons-04.txt draft-lear-lisp-nerd-04.txt draft-curran-lisp-emacs-00.txt IETF Dublin - July 2008

  4. LISP Problem Statement • Improve site multi-homing • Allow site control ingress traffic paths • Avoid renumbering by providing for portable addresses • Do it with lower OpEx • Improve Traffic Engineering for ISPs • Use level of indirection rather than more specific injection • Reduce core routers routing table size • Aid in IPv4 to IPv6 transition • Provide Server Load Balancing in Data Center • Some form of mobility IETF Dublin - July 2008

  5. LISP Conceptually • IPv4 and IPv6 addresses have overloaded semantics • LISP separates Location from ID • Introduces 2 address spaces: • Endpoint IDs (EIDs) • Routing Locators (RLOCs) • Use 32-bit EIDs for IPv4 from registry allocation • Use 128-bit EIDs for IPv6 from registry allocation • Use topological addresses for Locators from ISP address block allocations IETF Dublin - July 2008

  6. S R2 R1 Multi-Level Addressing Provider A 10.0.0.0/8 Provider B 11.0.0.0/8 RLOCs used in the core Mapping Database Entry: 1.0.0.0/8 -> (10.0.0.1, 11.0.0.1) 11.0.0.1 10.0.0.1 EIDs are inside of sites 1.0.0.0/8 IETF Dublin - July 2008

  7. Mapping Entry: EID-prefix: 2.0.0.0/8 Locator-set (RLOCs): 12.0.0.2, priority: 1, weight: 50 13.0.0.2, priority: 1, weight: 50 Host Stack: supplies EIDs LISP Router: supplies RLOCs by adding new header LISP is Map-n-Encap IETF Dublin - July 2008

  8. LISP Solution Space • LISP - Locator/ID Separation Protocol • Network-based solution • No changes to hosts whatsoever • No new addressing changes to site devices • Very few configuration file changes • Imperative to be incrementally deployable • Address family agnostic IETF Dublin - July 2008

  9. S D 11.0.0.1 -> 12.0.0.2 11.0.0.1 -> 12.0.0.2 EID-prefix: 2.0.0.0/8 Locator-set: 12.0.0.2, priority: 1, weight: 50 (D1) 13.0.0.2, priority: 1, weight: 50 (D2) Mapping Entry 1.0.0.1 -> 2.0.0.2 1.0.0.1 -> 2.0.0.2 1.0.0.1 -> 2.0.0.2 1.0.0.1 -> 2.0.0.2 S1 S2 D1 D2 Policy controlled by destination site Unicast Packet Forwarding PI EID-prefix 1.0.0.0/8 PI EID-prefix 2.0.0.0/8 ETR ITR Provider A 10.0.0.0/8 Provider X 12.0.0.0/8 12.0.0.2 10.0.0.1 ITR ETR 11.0.0.1 13.0.0.2 Provider B 11.0.0.0/8 Provider Y 13.0.0.0/8 DNS entry: D.abc.com A2.0.0.2 Legend: EIDs -> Green Locators -> Red IETF Dublin - July 2008

  10. S S S D D D X X X EID-prefix: 2.0.0.0/8 Locator-set: 12.0.0.2, priority: 1, weight: 50 (D1) 13.0.0.2, priority: 1, weight: 50 (D2) Mapping Entry 0003 D1 D2 0003 0002 D2 D2 D2 D2 D2 D1 7654 3210 b’xxxx xxxx’ D2 D1 S2 S1 Locator Reachability PI EID-prefix 2.0.0.0/8 ETR ITR Provider A 10.0.0.0/8 Provider X 12.0.0.0/8 12.0.0.2 10.0.0.1 ITR ETR 11.0.0.1 13.0.0.2 Provider B 11.0.0.0/8 Provider Y 13.0.0.0/8 loc-reach-bits: 0x0000 0003 -> ordinal 0 -> ordinal 1 Legend: EIDs -> Green Locators -> Red IETF Dublin - July 2008

  11. Changing Mapping Entries • A “change” is defined to be: • Adding a locator to a locator-set • Changing an existing locator’s priority or weight (for either unicast or multicast) • Removing a locator from a locator-set • Adding entries is simple • Append to the end, new loc-reach-bit allocated and set • Old cachers ignore loc-reach-bit set for non-existent locator • New cachers use new locator-set and all loc-reach-bits IETF Dublin - July 2008

  12. Changing Mapping Entries • Removing a locator is done by: • Set loc-reach-bit to 0 • “Zero-fill” address in slot, set priority 255 • Old cachers have non-zero slot but don’t use locator since loc-reach-bit 0 • New cachers see empty 255 slot and don’t use • Changing priority or weights • Use Clock Sweep or SMRs IETF Dublin - July 2008

  13. EID-prefix: 153.16.1.0/24, loc-reach-bits: 0x001d, locator-set: 1.0.0.1, priority: 1, weight: 25 0.0.0.0, priority: 255, weight: 25 3.0.0.3, priority: 1, weight: 25 4.0.0.4, priority: 1, weight: 25 5.0.0.5, priority: 1, weight: 25 delete add Changing Mapping Entries EID-prefix: 153.16.1.0/24, loc-reach-bits: 0x000f, locator-set: 1.0.0.1, priority: 1, weight: 25 2.0.0.2, priority: 1, weight: 25 3.0.0.3, priority: 1, weight: 25 4.0.0.4, priority: 1, weight: 25 Changed providers: 2.0.0.2 disconnect and 5.0.0.5 connects Over time compaction may be required to get loc-reach-bits back! IETF Dublin - July 2008

  14. Locator-Set Compaction Changes • Operational Mechanism • Clock Sweep • Protocol Mechanism • Solicit Map-Requests (SMRs) IETF Dublin - July 2008

  15. 24 hours 1 hour 1 minute TTL = 24 cachers time out, TTL = 1 cachers have been timing out each hour Change process ends Start the change process TTL = 1 hour cachers time out, TTL = 1 minute cachers have been timing out each minute Clock Sweep Send Map-Replies with old mapping with TTL = 1 minute Send Map-Replies with old mapping with TTL = 1 hour Send Map-Replies with new mapping with TTL = 24 hours time (not to scale) IETF Dublin - July 2008

  16. Solicit Map-Requests (SMRs) • Used when a site needs compaction • Sites solicit Map-Requests from active sites • SMR-bit is in encapsulated LISP header • ITRs rate limit to control the number and rate of Map-Requests they want to receive • Remote ITRs rate-limit Map-Requests until they get a Map-Reply with the new database mapping entry • Nonce from SMR copied to Map-Request copied to Map-Reply • Map-Request can be sent either on ALT or underlying network • Local ITR keeps track of which site has new versus old mappings for appropriate loc-reach-bit setting • No map versioning required • Recommendation is to have only one outstanding change IETF Dublin - July 2008

  17. Mixed locator-set Mixed Locators • What are mixed locators? dr22# sh ip lisp map-cache LISP IP Mapping Cache for VRF "default" - 1 entries 240.23.0.0/24, uptime: 00:00:14, state: complete, last modified: 00:00:14 1.22.23.23, uptime: 00:00:14, state: up, priority/weight: 1/50 11.22.23.23, uptime: 00:00:14, state: up, priority/weight: 1/50 dr22# sh ipv6 lisp map-cache LISP IPv6 Mapping Cache for VRF "default" - 1 entries 0240:0023::/32, uptime: 00:22:00, state: complete, last modified: 00:22:00 dfdf:2223::0023, uptime: 00:22:00, state: up, priority/weight: 1/33 1.22.23.23, uptime: 00:22:00, state: up, priority/weight: 1/33 11.22.23.23, uptime: 00:22:00, state: up, priority/weight: 1/33 IETF Dublin - July 2008

  18. Mixed Locators • LISP-ALT needs to be dual-stack • Data Probes and Map-Requests are homogenous • EID needs to be in destination address • Map-Reply is sent on the underlying network • Therefore underlying has to be dual-stack • But IPv6 is not ubiquitous so we need IPv4 Map-Replies for IPv6 Data Probes or Map-Requests IETF Dublin - July 2008

  19. Mixed Locators - Some Cautions • Locator Reachability tells you that xTR is up • Doesn’t tell you what the AF path is from you to the ETR • Hashing considerations • Destination EID hashes to AF RLOC • Source RLOC must be same AF • Setting priorities for a mixed locator-set is difficult • Because you don’t know AF path for requesting source site • Better to have “crossed sets” • IPv4 EIDs -> all IPv6 RLOCs (China and Japan deployments) • IPv6 EIDs -> all IPv4 RLOCs (US deployments) IETF Dublin - July 2008

  20. S D D1 S2 D2 S1 Mixed Locators are Useful ETR ITR Provider A 10.0.0.0/8 Provider X 12.0.0.0/8 12.0.0.2 10.0.0.1 ITR ETR 11.0.0.1 13.0.0.2 IPv6-only IPv6-only Provider B 11.0.0.0/8 Provider Y 13.0.0.0/8 IPv4 Internet Legend: EIDs -> Green Locators -> Red IETF Dublin - July 2008

  21. S S D D IPv4 IPv6 IPv6 IPv4/IPv6 IPv4/IPv6 E1 S1 S2 D1 D2 E2 IPv4/IPv6 Mixed Locators are Useful ETR ITR Provider A 10.0.0.0/8 Provider X 12.0.0.0/8 12.0.0.2 10.0.0.1 ITR Dual-stack ETR 11.0.0.1 13.0.0.2 IPv6-only Provider B 11.0.0.0/8 Provider Y 13.0.0.0/8 13::/16 13.0.0.22 Partly Dual-Stack Internet 13::.21 Legend: EIDs -> Green Locators -> Red Dual-stack IETF Dublin - July 2008

  22. Spec Diffs between -06 to -08 • Lots of clarification text from many reviewers • Clearly specify only 2 LISP headers can be prepended • First one for Loc/ID split by CPE router • Second one for TE by ISP router • Add SMR-bit to data header and Map-Request • Steal a loc-reach-bit • Specify how to select a source UDP port number IETF Dublin - July 2008

  23. Spec Diffs between -06 to -08 • Added mpriority and mweight • So locator selection can be different for unicast or multicast flows • Updated section on LISP-Multicast to summarize details in draft-farinacci-lisp-multicast-00.txt • When ITR receives ICMP unreachable • It may originate one to the source host inside of its site • Add section on locator hashing for equal-priority locators • Add sections for Clock Sweep and SMRs • Updated milestone section IETF Dublin - July 2008

  24. Rough Set of Milestones 1. This draft will be the draft for interoperable implementations to code against. Interoperable implementations will be ready summer of 2008. 2. Continue pilot deployment summer of 2008 using LISP-ALT as the database mapping mechanism. 3. Continue prototyping other database lookup schemes, be it DNS, DHTs, CONS, ALT, NERD, or other mechanisms. 4. Implement the LISP Multicast draft [MLISP]. 5. Research more on how policy affects what gets returned in a Map- Reply from an ETR. 6. Continue to experiment with mixed locator-sets to understand how LISP can help the IPv4 to IPv6 transition. IETF Dublin - July 2008

  25. Accomplishments 1. A unit- and system-tested software switching implementation has been completed on cisco NX-OS for this draft for both IPv4 and IPv6 EIDs using a mixed locator-set of IPv4 and IPv6 locators. 2. A unit- and system-tested software switching implementation on cisco NX-OS has been completed for draft for [ALT]. 3. A unit- and system-tested software switching implementation on cisco NX-OS has been completed for draft [INTERWORK]. Support for IPv4 translation is provided and PTR support for IPv4 and IPv6 is provided. 4. The cisco NX-OS implementation supports an experimental mechanism for slow mobility. 5. Dave Meyer, Vince Fuller, Darrel Lewis, Greg Shepherd, and Andrew Partan continue to test all the features described above on a dual-stack infrastructure. 6. Darrel Lewis and Dave Meyer have deployed both LISP translation and LISP PTR support in the pilot network. Point your browser to http://www.lisp4.net to see translation happening in action so your non-LISP site can access a web server in a LISP site. 7. Soon http://www.lisp6.net will work where your IPv6 LISP site can talk to a IPv6 web server in a LISP site by using mixed addres- family based locators. 8. An public domain implementation of LISP is underway. See [OPENLISP] for details. 9. A cisco IOS implementation is underway which currently supports IPv4 encapsulation and decapsulation features. IETF Dublin - July 2008

  26. Open Issues • Experiment with more-specific mappings and policy-based Map-Reply priority changing • ISP resident TE-xTR functionality with another “multi-level LISP” hierarchy • Firm up details on LISP-Multicast • LISP can do some form of mobility • More specific state only at edges in xTRs • Can we extend it for secure and graceful handoff • Continue prototyping ideas and deploying on pilot network • Interoperability testing of NX-OS, IOS, and OpenLISP IETF Dublin - July 2008

  27. lisp-interest@lists.civil-tongue.net IETF Dublin - July 2008

More Related