Transcript LISP+ALT Mapping System 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)
Agenda
•
•
•
•
LISP BOF
Mapping system design needs
Ideas we considered
Brief summary of LISP+ALT
Open issues
IETF Dublin, July, 2008
Slide 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
IETF Dublin, July, 2008
Slide 3
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?
LISP BOF
IETF Dublin, July, 2008
Slide 4
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
LISP BOF
IETF Dublin, July, 2008
Slide 5
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
LISP BOF
IETF Dublin, July, 2008
Slide 6
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
LISP BOF
IETF Dublin, July, 2008
Slide 7
LISP+ALT in action
EID-prefix
240.0.0.0/24
?
ITR
Legend:
?
?
< - 240.1.0.0/16
ALT-rtr
ALT-rtr
ETR
EID-prefix
240.1.1.0/24
ALT-rtr
ALT-rtr
ALT-rtr
EIDs -> Green
240.0.0.1 -> 240.1.1.1
240.0.0.1 -> 240.1.1.1
240.0.0.1 -> 240.1.1.1
ITR
240.0.0.1 -> 240.1.1.1
11.0.0.1 -> 240.1.1.1
11.0.0.1 -> 240.1.1.1
ETR
ALT-rtr
Locators -> Red
GRE Tunnel
LAT
Low Opex
Physical link
Data Packet
Map-Request
Map-Reply
LISP BOF
ETR
11.0.0.1 -> 1.1.1.1
?
240.0.0.1 -> 240.1.1.1
1.1.1.1 -> 11.0.0.1
IETF Dublin, July, 2008
Slide 8
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?
LISP BOF
IETF Dublin, July, 2008
Slide 9
Issue: EID assignment
Provider A
10.0.0.0/8
ISP allocates 1 locator address
per physical attachment point
(follows network topology)
R1
Legend:
EIDs -> Green
Locators -> Red
LISP BOF
R2
Provider B
11.0.0.0/8
RIR allocates EID-prefixes
(follows org/geo hierarchy)
Site
PI EID-prefix 240.1.0.0/16
IETF Dublin, July, 2008
Slide 10
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
LISP BOF
IETF Dublin, July, 2008
Slide 11
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?
LISP BOF
IETF Dublin, July, 2008
Slide 12
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 morespecific mappings for simple TE
• Alternative to current practice of
advertising more-specific prefixes
LISP BOF
IETF Dublin, July, 2008
Slide 13
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 morespecifics with MEDs…today is not
that day, unfortunately)
LISP BOF
IETF Dublin, July, 2008
Slide 14
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 EIDprefix route” pointing to ETR
– originates EID prefix on behalf of ETR
LISP BOF
IETF Dublin, July, 2008
Slide 15
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?
LISP BOF
IETF Dublin, July, 2008
Slide 16
Questions/Comments?
Contact us: [email protected]
Information: http://www.lisp4.net
OpenLISP: http://inl.info.ucl.ac.be
Thanks!
LISP BOF
IETF Dublin, July, 2008
Slide 17