LISP BOF Update draftfarinaccilisp08 txt Dino Farinacci Dave
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 LISP BOF Update IETF Dublin - July 2008 2
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 LISP BOF Update IETF Dublin - July 2008 3
LISP Problem Statement • Improve site multi-homing – Allow site control ingress traffic paths – Avoid renumbering by providing for portable addresses – Do it with lower Op. Ex • Improve Traffic Engineering for ISPs – Use level of indirection rather than more specific injection • • Reduce core routers routing table size Aid in IPv 4 to IPv 6 transition Provide Server Load Balancing in Data Center Some form of mobility LISP BOF Update IETF Dublin - July 2008 4
LISP Conceptually • IPv 4 and IPv 6 addresses have overloaded semantics • LISP separates Location from ID • Introduces 2 address spaces: – Endpoint IDs (EIDs) – Routing Locators (RLOCs) • Use 32 -bit EIDs for IPv 4 from registry allocation • Use 128 -bit EIDs for IPv 6 from registry allocation • Use topological addresses for Locators from ISP address block allocations LISP BOF Update IETF Dublin - July 2008 5
Multi-Level Addressing Provider A 10. 0/8 0. 1 11. . 0. 0 10 . 1 Provider B 11. 0. 0. 0/8 R 1 R 2 S RLOCs used in the core Mapping Database Entry: 1. 0. 0. 0/8 -> (10. 0. 0. 1, 11. 0. 0. 1) EIDs are inside of sites 1. 0. 0. 0/8 LISP BOF Update IETF Dublin - July 2008 6
LISP is Map-n-Encap Host Stack: supplies EIDs 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 LISP Router: supplies RLOCs by adding new header LISP BOF Update IETF Dublin - July 2008 7
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 LISP BOF Update IETF Dublin - July 2008 8
Unicast Packet Forwarding PI EID-prefix 1. 0. 0. 0/8 ITR S 1 S ITR S 2 PI EID-prefix 2. 0. 0. 0/8 Provider A 10. 0/8 10. 0. 0. 1 ETR Provider X 12. 0. 0. 0/8 12. 0. 0. 2 11. 0. 0. 1 Provider B 11. 0. 0. 0/8 . 0. 0. 2 13 ETR D D 2 Provider Y 13. 0. 0. 0/8 1. 0. 0. 1 -> 2. 0. 0. 2 11. 0. 0. 1 -> 12. 0. 0. 2 DNS entry: D. abc. com D 1 11. 0. 0. 1 -> 12. 0. 0. 2 1. 0. 0. 1 -> 2. 0. 0. 2 A 2. 0. 0. 2 EID-prefix: 2. 0. 0. 0/8 Mapping Legend: EIDs -> Green Locators -> Red LISP BOF Update 1. 0. 0. 1 -> 2. 0. 0. 2 Entry Locator-set: 12. 0. 0. 2, priority: 1, weight: 50 (D 1) 13. 0. 0. 2, priority: 1, weight: 50 (D 2) IETF Dublin - July 2008 Policy controlled by destination site 9
Locator Reachability PI EID-prefix 2. 0. 0. 0/8 D 2 S S S 1 ITR S 2 D 1 D ITR S 2 10. 0. 0. 1 Provider A 10. 0/8 Provider X 12. 0. 0. 0/8 11. 0. 0. 1 D 2 Provider B 11. 0. 0. 0/8 Provider Y 13. 0. 0. 0/8 EID-prefix: 2. 0. 0. 0/8 Mapping Entry EIDs -> Green Locators -> Red LISP BOF Update X . 2 13. 0. 0 D 2 Legend: X X 0003 ETR 12. 0. 0. 2 D 1 D D ETR D 2 D 0002 0003 loc-reach-bits: 0 x 0000 0003 Locator-set: 12. 0. 0. 2, priority: 1, weight: 50 (D 1) -> ordinal 0 13. 0. 0. 2, priority: 1, weight: 50 (D 2) -> ordinal 1 IETF Dublin - July 2008 7654 3210 b’xxxx’ 10
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 LISP BOF Update IETF Dublin - July 2008 11
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 LISP BOF Update IETF Dublin - July 2008 12
Changing Mapping Entries EID-prefix: 153. 16. 1. 0/24, loc-reach-bits: 0 x 000 f, 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 EID-prefix: 153. 16. 1. 0/24, loc-reach-bits: 0 x 001 d, locator-set: delete 1. 0. 0. 1, priority: 1, weight: 25 0. 0, priority: 255, weight: 25 3. 0. 0. 3, priority: 1, weight: 25 add Over time compaction may be required to get loc-reach-bits back! 4. 0. 0. 4, priority: 1, weight: 25 5. 0. 0. 5, priority: 1, weight: 25 LISP BOF Update IETF Dublin - July 2008 13
Locator-Set Compaction Changes • Operational Mechanism – Clock Sweep • Protocol Mechanism – Solicit Map-Requests (SMRs) LISP BOF Update IETF Dublin - July 2008 14
Clock Sweep Send Map-Replies with old mapping with TTL = 1 hour time Send Map-Replies with old mapping with TTL = 1 minute Send Map-Replies with new mapping with TTL = 24 hours (not to scale) 24 hours Start the change process 1 hour TTL = 24 cachers time out, TTL = 1 cachers have been timing out each hour 1 minute Change process ends TTL = 1 hour cachers time out, TTL = 1 minute cachers have been timing out each minute LISP BOF Update IETF Dublin - July 2008 15
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 LISP BOF Update IETF Dublin - July 2008 16
Mixed Locators • What are mixed locators? dr 22# sh ip lisp map-cache LISP IP Mapping Cache for VRF "default" - 1 entries 240. 23. 0. 0/24, uptime: 00: 14, state: complete, last modified: 00: 14 1. 22. 23, uptime: 00: 14, state: up, priority/weight: 1/50 11. 22. 23, uptime: 00: 14, state: up, priority/weight: 1/50 dr 22# sh ipv 6 lisp map-cache LISP IPv 6 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, uptime: 00: 22: 00, state: up, priority/weight: 1/33 11. 22. 23, uptime: 00: 22: 00, state: up, priority/weight: 1/33 Mixed locator-set LISP BOF Update IETF Dublin - July 2008 17
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 IPv 6 is not ubiquitous so we need IPv 4 Map. Replies for IPv 6 Data Probes or Map-Requests LISP BOF Update IETF Dublin - July 2008 18
Mixed Locators - Some Cautions • Locator Reachability tells you that x. TR 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” • IPv 4 EIDs -> all IPv 6 RLOCs (China and Japan deployments) • IPv 6 EIDs -> all IPv 4 RLOCs (US deployments) LISP BOF Update IETF Dublin - July 2008 19
Mixed Locators are Useful ITR S 1 S ITR IPv 6 -only S 2 10. 0. 0. 1 Provider A 10. 0/8 Provider X 12. 0. 0. 0/8 11. 0. 0. 1 ETR 12. 0. 0. 2 13. 0. 0 Provider B 11. 0. 0. 0/8 D 1 ETR D 2 D IPv 6 -only Provider Y 13. 0. 0. 0/8 IPv 4 Internet Legend: EIDs -> Green Locators -> Red LISP BOF Update IETF Dublin - July 2008 20
Mixed Locators are Useful IPv 4 6 IPv S ITR S 1 ITR IPv 6 -only S 2 10. 0. 0. 1 Provider A 10. 0/8 IP ETR Provider X 12. 0. 0. 0/8 11. 0. 0. 1 Provider B 11. 0. 0. 0/8 . 2 13. 0. 0 Provider Y 13. 0. 0. 0/8 13: : /16 S . 2 1 22 : : . . 0 Locators -> Red Dual-stack IPv 4/IPv 6 IPv 4/ E 1 IPv 4/IPv 6 EIDs -> Green D 2 D . 0 13 E 2 Legend: ETR 6 13 Partly Dual-Stack Internet LISP BOF Update D 1 12. 0. 0. 2 v 6 D Dual-stack IETF Dublin - July 2008 21
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 LISP BOF Update IETF Dublin - July 2008 22
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 LISP BOF Update IETF Dublin - July 2008 23
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 IPv 4 to IPv 6 transition. LISP BOF Update IETF Dublin - July 2008 24
Accomplishments 1. A unit- and system-tested software switching implementation has been completed on cisco NX-OS for this draft for both IPv 4 and IPv 6 EIDs using a mixed locator-set of IPv 4 and IPv 6 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 IPv 4 translation is provided and PTR support for IPv 4 and IPv 6 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. lisp 4. 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. lisp 6. net will work where your IPv 6 LISP site can talk to a IPv 6 web server in a LISP site by using mixed addresfamily based locators. 8. An public domain implementation of LISP is underway. [OPENLISP] for details. 9. A cisco IOS implementation is underway which currently supports IPv 4 encapsulation and decapsulation features. LISP BOF Update IETF Dublin - July 2008 See 25
Open Issues • Experiment with more-specific mappings and policy-based Map. Reply priority changing • ISP resident TE-x. TR 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 x. TRs – Can we extend it for secure and graceful handoff • Continue prototyping ideas and deploying on pilot network • Interoperability testing of NX-OS, IOS, and Open. LISP BOF Update IETF Dublin - July 2008 26
lisp-interest@lists. civil-tongue. net LISP BOF Update IETF Dublin - July 2008 27
- Slides: 27