LISP+ALT Mapping System

1. LISP+ALT Mapping System LISP BOF, IETF Dublin, July, 2008 Vince Fuller (for the LISP crew)

2. Agenda • Mapping system design needs • Ideas we considered • Brief summary of LISP+ALT • 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. Mapping system: what and why • Need a scalable EID to Locator mapping lookup mechanism • Network based solutions • Have query/reply latency • Can have packet loss characteristics • Or, have a full table like BGP does • How does one design a scalable Mapping Service? IETF Dublin, July, 2008

5. Scaling constraints • 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(1010) hosts • Aggregate EIDs into EID-prefixes to reduce state • rate must be small • Damp locator reachability status and locator-set changes • Each mapping system design does it differently IETF Dublin, July, 2008

6. Tough questions/issues • Where to store the mappings? • How to find the mappings? • Push model or pull model? • Full database or cache? Secondary storage? • How to secure mapping entries? • How to secure control messages? • Protecting infrastructure from attacks • Control over packet loss and latency IETF Dublin, July, 2008

7. LISP+ALT: What, How, Why • Hybrid push/pull approach • ALT pushes aggregates - find ETRs for EID • ITR uses LISP to find RLOCs for specific EID • Hierarchical EID assignment (geo?) • Aggregation of EID prefixes • Tunnel-based overlay network • BGP used to advertise EIDs on overlay • Use existing technology (and not DNS) • Option for data-triggered Map-Replies IETF Dublin, July, 2008

8. 11.0.0.1 -> 240.1.1.1 11.0.0.1 -> 240.1.1.1 240.0.0.1 -> 240.1.1.1 240.0.0.1 -> 240.1.1.1 <- 240.1.1.0/24 < - 240.1.0.0/16 <- 240.1.2.0/24 240.0.0.1 -> 240.1.1.1 240.0.0.1 -> 240.1.1.1 ITR ITR ETR ETR ETR 11.0.0.1 -> 1.1.1.1 ? ? ? ? 1.1.1.1 -> 11.0.0.1 240.0.0.1 -> 240.1.1.1 ALT-rtr ALT-rtr ALT-rtr ALT-rtr ALT-rtr ALT-rtr LISP+ALT in action EID-prefix 240.0.0.0/24 EID-prefix 240.1.1.0/24 1.1.1.1 11.0.0.1 2.2.2.2 12.0.0.1 Legend: EIDs -> Green Locators -> Red GRE Tunnel Low Opex Physical link Data Packet Map-Request Map-Reply 3.3.3.3 LAT IETF Dublin, July, 2008

9. Issue: Data-Triggered Mappings • ITR may forward data for “un-mapped” EID into ALT, attached to a Map-Request • LISP Map-Reply returned from ETR to ITR, uses “native” path, installed in ITR cache • ETR delivers attached data to end host • Subsequent traffic uses cached RLOCs • Scaling/complexity/performance issues • Is this (Data Probes) a good idea? IETF Dublin, July, 2008

10. ISP allocates 1 locator address per physical attachment point (follows network topology) RIR allocates EID-prefixes (follows org/geo hierarchy) R1 R2 Issue: EID assignment Provider A 10.0.0.0/8 Provider B 11.0.0.0/8 11.0.0.1 10.0.0.1 Site Legend: EIDs -> Green Locators -> Red PI EID-prefix 240.1.0.0/16 IETF Dublin, July, 2008

11. Separate EID/RLOC topologies “Addressing can follow topology or topology can follow addressing – choose one” –Y.R. • ID/LOC separation avoids this dilemma • EIDs uses organization/geo hierarchy • RLOCs follow network topology • Reduce global routing state through RLOC aggregation • EID prefixes are not generally visible in global routing system IETF Dublin, July, 2008

12. Issue: mapping system security • ALT can use existing/proposed BGP security mechanisms (SBGP, etc.) • DOS-mitigation using well-known control plane rate-limiting techniques • Nonce in LISP protocol exchange • More needed? IETF Dublin, July, 2008

13. Issue: large-site ETR policy • ALT separates ETR discovery from the ITR-ETR mapping exchange • very coarse prefixes advertised globally • more-specific info exchanged where needed • Regional ETRs could return more- specific mappings for simple TE • Alternative to current practice of advertising more-specific prefixes IETF Dublin, July, 2008

14. Large-site ETR policy example • (someday, this will be a pretty, animated slide that shows how LISP and ALT can achieve the same “best exit” effect as advertising more-specifics with MEDs…today is not that day, unfortunately) IETF Dublin, July, 2008

15. Issue: “low-opex” xTR • BGP configuration complexity is a barrier to site-multihoming • Remove xTR/CPE BGP requirement: • ITR has “static default EID-prefix route” to “first hop” ALT router • “first hop” ALT router has “static EID-prefix route” pointing to ETR • originates EID prefix on behalf of ETR IETF Dublin, July, 2008

16. Other issues to consider • Who runs the ALT network? • What’s the business model? • Should it be rooted at/run by the RIRs? • Different levels run by different orgs • Should it be free? • Others? IETF Dublin, July, 2008

17. Questions/Comments? Contact us: lisp-interest@lists.civil-tongue.net Information: http://www.lisp4.net OpenLISP: http://inl.info.ucl.ac.be Thanks! IETF Dublin, July, 2008 Slide 17