lisp bof, ietf dublin, july, 2008 vince fuller (for the lisp crew) lisp+alt mapping system

LISP BOF, IETF Dublin, July, 2008

Vince Fuller (for the LISP crew)

LISP+ALT Mapping SystemLISP+ALT Mapping System

LISP BOFLISP BOF IETF Dublin, July, 2008IETF Dublin, July, 2008 Slide Slide 22

AgendaAgenda

• Mapping system design needs

• Ideas we considered• Brief summary of LISP+ALT• Open issues


LISP Internet DraftsLISP Internet Draftsdraft-farinacci-lisp-08.txtdraft-fuller-lisp-alt-02.txtdraft-lewis-lisp-interworking-01.txtdraft-farinacci-lisp-multicast-00.txtdraft-meyer-lisp-eid-block-01.txt

draft-mathy-lisp-dht-00.txtdraft-iannone-openlisp-implementation-01.txtdraft-brim-lisp-analysis-00.txt

draft-meyer-lisp-cons-04.txtdraft-lear-lisp-nerd-04.txtdraft-curran-lisp-emacs-00.txt


Mapping system: what and Mapping system: what and whywhy

• 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?


Scaling constraintsScaling 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


Tough questions/issuesTough 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


LISP+ALT: What, How, LISP+ALT: What, How, WhyWhy

• 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


Legend:

EIDs -> Green

Locators -> Red

GRE Tunnel

Low Opex

Physical link

Data Packet

Map-Request

Map-Reply

ETR

ETR

ETR

ITR

ITR

EID-prefix

240.1.1.0/24

LAT

240.0.0.1 -> 240.1.1.1

1.1.

1.1

2.2.2.2

3.3.3.3

240.0.0.1 -> 240.1.1.1EID-prefix

240.0.0.0/24

1.1.1.1 -> 11.0.0.1240.0.0.1 -> 240.1.1.1

11.0.0.1 -> 1.1.1.1

ALT-rtr

ALT-rtr

ALT-rtr

ALT-rtr

ALT-rtr

ALT-rtr

12.0.0.1

11.0.0.1

?

240.0.0.1 -> 240.1.1.1

11.0.0.1 -> 240.1.1.1

? 240.0.0.1 -> 240.1.1.1

11.0.0.1 -> 240.1.1.1

?<- 2

40.1.1.0

/24

<- 240.1.2.0/24

< - 240.1.0.0/16

?

LISP+ALT in actionLISP+ALT in action


Issue: Data-Triggered Issue: Data-Triggered MappingsMappings

• 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?


Issue: EID assignmentIssue: EID assignment

Provider A10.0.0.0/8

Provider B11.0.0.0/8

R1 R2

PI EID-prefix 240.1.0.0/16

10.0.0.1 11.0.0.1

ISP allocates 1 locator address per physical attachment point(follows network topology)

RIR allocates EID-prefixes(follows org/geo hierarchy)

SiteLegend:

EIDs -> Green

Locators -> Red


Separate EID/RLOC Separate EID/RLOC topologiestopologies

• 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

“Addressing can follow topology or topology can follow

addressing – choose one” –Y.R.


Issue: mapping system Issue: mapping system securitysecurity

• 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?


Issue: large-site ETR Issue: large-site ETR policypolicy

• 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


Large-site ETR policy Large-site ETR policy exampleexample

• (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)


Issue: “low-opex” xTRIssue: “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


Other issues to Other issues to considerconsider

• 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?


Questions/Comments?Questions/Comments?

Slide Slide 1717

Thanks!

Contact us: [email protected]: http://www.lisp4.netOpenLISP: http://inl.info.ucl.ac.be

lisp bof, ietf dublin, july, 2008 vince fuller (for the lisp crew) lisp+alt mapping system

Documents