1. LISP-CONS A Mapping Database Service IETF/IRTF - July 2007 Dave Meyer Dino Farinacci Vince Fuller Darrel Lewis Scott Brim Noel Chiappa

2. LISP-CONS for RRGIETF/IRTFSlide 2 Agenda Brief Intro Design Considerations Brief Definitions How CONS Works Hybrid Approaches –Combining NERD and CONS –Combining APT and CONS –Is LISP 1.5 sufficient?

3. LISP-CONS for RRGIETF/IRTFSlide 3 Problem Statement Operationally –Improve site multihoming –Improve ISP Traffic Engineering –Reduce site renumbering costs –Reduce size of core routing tables –PI for all? –Some form of mobility? Architecturally –Create two namespaces: IDs and Locators

4. LISP-CONS for RRGIETF/IRTFSlide 4 Splitting an Address 2001:0102:0304:0506:1111:2222:3333:4444 LocatorID IPv6: 209.131.36.158IPv4: Locator.10.0.0.1 ID

5. LISP-CONS for RRGIETF/IRTFSlide 5 LISP is a Jack-Up Host Stack Uses IDs Map-n-EncapUses Locators

6. LISP-CONS for RRGIETF/IRTFSlide 6 LISP Parts Data-plane –Design for encapsulation and tunnel router placement –Design for locator reachability –Data triggered mapping service Control-plane –Design for a scalable mapping service

7. LISP-CONS for RRGIETF/IRTFSlide 7 LISP Variants LISP 1 –Routable IDs over existing topology to probe for mapping reply LISP 1.5 –Routable IDs over another topology to probe for mapping reply LISP 2 –EIDs are not routable and mappings are in DNS LISP 3 –EIDs are not routable, mappings obtained using new mechanisms (DHTs perhaps, LISP-CONS, NERD, APT) Data-Plane Mapping Control-Plane Mapping

8. LISP-CONS for RRGIETF/IRTFSlide 8 Quick LISP Terms Endpoint Identifiers (EIDs) –IDs for host-use and routeable in source and dest sites –Can be out of PA or PI address space Routing Locators (RLOCs) –Routeable addresses out of PA address space Ingress Tunnel Router (ITR) –Device in source-site that prepends LISP header with RLOCs Egress Tunnel Router (ETR) –Device in destination-site that strips LISP header

9. LISP-CONS for RRGIETF/IRTFSlide 9 LISP Control-Plane Build a large distributed mapping database service Scalability paramount to solution How to scale: (state * rate) If both factors large, we have a problem –state will be O(10 10 ) hosts –Aggregate EIDs into EID-prefixes to reduce state –So rate must be small –Make mappings have “subscription time” frequency

10. LISP-CONS for RRGIETF/IRTFSlide 10 LISP Control-Plane Where to put the mappings? How to find the mappings? Is it a push model? Is it a pull model? Do you use secondary storage? Do you use a cache? What about securing the mapping entries? What about protecting infrastructure from DOS-attacks? What about controlling packet loss and latency?

11. LISP-CONS for RRGIETF/IRTFSlide 11 LISP Control-Plane “Push doesn’t scale, caching doesn’t scale, pick one”

12. LISP-CONS for RRGIETF/IRTFSlide 12 LISP-CONS We have chosen a hybrid approach Push at upper levels of hierarchy Pull from lower levels of hierarchy Mappings stay at lower-levels –Requests get to where the mappings are –Replies are returned Getting to the lower-levels via pushing of EID- prefixes LISP-CONS is a mapping system for LISP 3.0 LISP-CONS is not a DHT

13. LISP-CONS for RRGIETF/IRTFSlide 13 LISP-CONS We can get good EID-prefix aggregation –If hierarchy based on EID-prefix allocation and not topology –Then build a logical topology based on the EID-prefix allocation Map-Requests routed through logical hierarchy –Key is the EID Map-Reply returned to originator –With mapping record {EID-prefix, Locator-set}

14. LISP-CONS for RRGIETF/IRTFSlide 14 LISP-CONS Network Elements Content Access Routers (CARs) –Querying-CARs Generate Map-Requests on behalf of ITRs –Replying-CARs Hold authoritative mappings at level-0 of hierarchy Aggregate only EID-prefix upwards Respond with Map-Replies Content Distribution Routers (CDRs) –Push around EID-prefixes with level-1 to n of hierarchy –Aggregate EID-prefix upwards –Advertise EID-prefixes in a mesh topology within level –Forward Map-Requests and Map-Replies

15. LISP-CONS for RRGIETF/IRTFSlide 15 LISP-CONS ITR ETR qCAR rCARqCARrCARqCAR Level-0 CDR Mesh CDR Level-1 qCAR Level-n CDR Mesh { 1.1.1.0/24: L1,L2 } Legend: { } : mapping entry [ ] : EID aggregate : mapping table { 1.1.2.0/24: L11,L22 } [ 1.1.0.0/16 ][ 1.0.0.0/8 ] Map-Request 1.1.1.1 No EID-Prefix within mesh, forward to parent peer Map-Request 1.1.1.1 No mapping cached,forward to parent peer Take shortest path to 1.0.0.0/8 Map-Request 1.1.1.1 Has more- specific entry downward CAR has mapping, returns Map-Reply to orig CAR EID address { 1.1.1.0/24: L1,L2 } { 1.1.2.0/24: L11,L22 }

16. LISP-CONS for RRGIETF/IRTFSlide 16 LISP-CONS CDR Mesh CDR Level-n Level-(n-1) Parent Peer Child Peer Sibling Peer CDR [ EID-prefix agg ] [ 0.0.0.0/0 ] All peering on TCP HMAC protected connections Within a CDR-mesh, EID-prefixes get seq num pushed with PV lists

17. LISP-CONS for RRGIETF/IRTFSlide 17 LISP-CONS CDR Mesh CDR Level-1 Level-0 Parent Peer Child Peer rCAR [ EID-prefix agg ] Sibling Peer All peering on TCP HMAC protected connections Within a CDR-mesh, EID-prefixes get seq num pushed with PV lists ETR

18. LISP-CONS for RRGIETF/IRTFSlide 18 Hybrid Models Combining brute-force push of NERD to CONS CARs Lower latency like with CONS caching since entire database stored in CAR ITR still caches and encapsulates directly to ETR

19. LISP-CONS for RRGIETF/IRTFSlide 19 ITR NERD with CONS ITR qCAR Level-0 qCAR NERD Authoritative and Signed Mapping Database ITR

20. LISP-CONS for RRGIETF/IRTFSlide 20 Hybrid Models Use CARs as Default Mappers (like APT) Use data packet as Map-Request Never a packet drop at expense of increased stretch Mappings between CARs are NERD pushed

21. LISP-CONS for RRGIETF/IRTFSlide 21 CARs are Default Mappers ITR ETR qCAR Level-0 qCAR NERD Authoritative and Signed Mapping Database { 1.1.1.0/24: L1,L2 } LiSP encaped to qCAR ITR has mapping: 0.0.0.0/0 -> qCAR Decaped and Reencaped to ETR Map-Reply

22. LISP-CONS for RRGIETF/IRTFSlide 22 Is LISP 1.5 Sufficient? Use an alternate topology to run BGP on EID namespace Use BGP to either pass mappings around –And use APT type forwarding Use BGP to pass only EID-prefixes –Send Map-Requests to find CARs –Use data probe ala LISP 1.5 and have ETRs return data-triggered Map-Replies

23. LISP-CONS for RRGIETF/IRTFSlide 23 LISP 1.5 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 PI EID-prefix 1.0.0.0/8 PI EID-prefix 2.0.0.0/8 1.0.0.1 -> 2.0.0.2 11.0.0.1 -> 2.0.0.2 Legend: EIDs -> Green Locators -> Red 1.0.0.1 -> 2.0.0.2 12.0.0.2 D2 13.0.0.2 Alternate Topology Running BGP on EID-prefixes 1.0.0.1 -> 2.0.0.2 11.0.0.1 -> 12.0.0.2 1.0.0.1 -> 2.0.0.2 11.0.0.1 -> 12.0.0.2 13.0.0.2 -> 11.0.0.1 Map-Reply 2.0.0.0/8 12.0.0.2, p: 1, w: 50 13.0.0.2, p: 1, w: 50

24. LISP-CONS for RRGIETF/IRTFSlide 24 Documentation Draft draft-farinacci-lisp-02.txt –UDP encapsulation –UDP for Map-Request & Map-Reply –Locator reach bits –Fixes from implementation experience Draft draft-meyer-lisp-cons-01.txt –A control-plane mapping service

25. LISP-CONS for RRGIETF/IRTFSlide 25 Oh, so it's just like a Blackberry!

26. LISP-CONS for RRGIETF/IRTFSlide 26