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. LISP BOF UpdateIETF Dublin - July 2008Slide 2 Agenda Overview of LISP Changing Mapping Database Entries Support for Mixed Locators Spec changes between -06 to -08 Open Issues

3. LISP BOF UpdateIETF Dublin - July 2008Slide 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

4. LISP BOF UpdateIETF Dublin - July 2008Slide 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

5. LISP BOF UpdateIETF Dublin - July 2008Slide 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

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

7. LISP BOF UpdateIETF Dublin - July 2008Slide 7 LISP is Map-n-Encap Host Stack: supplies EIDs LISP Router: supplies RLOCs by adding new header 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 Mapping Entry:

8. LISP BOF UpdateIETF Dublin - July 2008Slide 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

9. LISP BOF UpdateIETF Dublin - July 2008Slide 9 Unicast Packet Forwarding Provider A 10.0.0.0/8 Provider B 11.0.0.0/8 S ITR D ETR Provider Y 13.0.0.0/8 Provider X 12.0.0.0/8 S1 S2 D1 D2 PI EID-prefix 1.0.0.0/8 PI EID-prefix 2.0.0.0/8 DNS entry: D.abc.com A 2.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 11.0.0.1 -> 12.0.0.2 Legend: EIDs -> Green Locators -> Red 1.0.0.1 -> 2.0.0.2 11.0.0.1 -> 12.0.0.2 1.0.0.1 -> 2.0.0.2 12.0.0.2 13.0.0.2 10.0.0.1 11.0.0.1 Policy controlled by destination site

10. LISP BOF UpdateIETF Dublin - July 2008Slide 10 Locator Reachability Provider A 10.0.0.0/8 Provider B 11.0.0.0/8 S ITR D ETR Provider Y 13.0.0.0/8 Provider X 12.0.0.0/8 S1 S2 D1 D2 PI EID-prefix 2.0.0.0/8 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 Legend: EIDs -> Green Locators -> Red 12.0.0.2 13.0.0.2 10.0.0.1 11.0.0.1 -> ordinal 0 -> ordinal 1 loc-reach-bits: 0x0000 0003 S S D D 0003 D1 D2 D1 D2 7654 3210 b’xxxx xxxx’ 0002 D2 X X X

11. LISP BOF UpdateIETF Dublin - July 2008Slide 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

12. LISP BOF UpdateIETF Dublin - July 2008Slide 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

13. LISP BOF UpdateIETF Dublin - July 2008Slide 13 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! 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

14. LISP BOF UpdateIETF Dublin - July 2008Slide 14 Locator-Set Compaction Changes Operational Mechanism –Clock Sweep Protocol Mechanism –Solicit Map-Requests (SMRs)

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

16. LISP BOF UpdateIETF Dublin - July 2008Slide 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

17. LISP BOF UpdateIETF Dublin - July 2008Slide 17 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 Mixed locator-set

18. LISP BOF UpdateIETF Dublin - July 2008Slide 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

19. LISP BOF UpdateIETF Dublin - July 2008Slide 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)

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

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

22. LISP BOF UpdateIETF Dublin - July 2008Slide 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

23. LISP BOF UpdateIETF Dublin - July 2008Slide 23 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 Spec Diffs between -06 to -08

24. LISP BOF UpdateIETF Dublin - July 2008Slide 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.

25. LISP BOF UpdateIETF Dublin - July 2008Slide 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.

26. LISP BOF UpdateIETF Dublin - July 2008Slide 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

27. LISP BOF UpdateIETF Dublin - July 2008Slide 27 lisp-interest@lists.civil-tongue.net