lisp bof update
Post on 12-Jan-2016
Embed Size (px)
DESCRIPTIONLISP BOF Update. draft-farinacci-lisp-08.txt Dino Farinacci, Dave Meyer, Vince Fuller, Darrel Lewis, Scott Brim, Dave Oran IETF Dublin - July 2008. Agenda. Overview of LISP Changing Mapping Database Entries Support for Mixed Locators Spec changes between -06 to -08 Open Issues. - PowerPoint PPT Presentation
LISP BOF Updatedraft-farinacci-lisp-08.txt
Dino Farinacci, Dave Meyer, Vince Fuller, Darrel Lewis,Scott Brim, Dave Oran
IETF Dublin - July 2008
AgendaOverview of LISPChanging Mapping Database EntriesSupport for Mixed LocatorsSpec changes between -06 to -08Open Issues
LISP 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
LISP Problem StatementImprove site multi-homingAllow site control ingress traffic pathsAvoid renumbering by providing for portable addressesDo it with lower OpExImprove Traffic Engineering for ISPsUse level of indirection rather than more specific injectionReduce core routers routing table sizeAid in IPv4 to IPv6 transitionProvide Server Load Balancing in Data CenterSome form of mobility
LISP ConceptuallyIPv4 and IPv6 addresses have overloaded semantics LISP separates Location from IDIntroduces 2 address spaces:Endpoint IDs (EIDs)Routing Locators (RLOCs)Use 32-bit EIDs for IPv4 from registry allocationUse 128-bit EIDs for IPv6 from registry allocationUse topological addresses for Locators from ISP address block allocations
Multi-Level AddressingProvider A10.0.0.0/8Provider B22.214.171.124/8EIDs are inside of sitesRLOCs used in the core126.96.36.199/810.0.0.111.0.0.1Mapping Database Entry: 188.8.131.52/8 -> (10.0.0.1, 184.108.40.206)
LISP is Map-n-Encap
LISP Solution SpaceLISP - Locator/ID Separation ProtocolNetwork-based solutionNo changes to hosts whatsoeverNo new addressing changes to site devicesVery few configuration file changesImperative to be incrementally deployableAddress family agnostic
Unicast Packet ForwardingProvider A10.0.0.0/8Provider B220.127.116.11/8ITRITRETRETRProvider Y18.104.22.168/8Provider X22.214.171.124/8PI EID-prefix 126.96.36.199/8PI EID-prefix 188.8.131.52/8
DNS entry:D.abc.com A 184.108.40.206Legend: EIDs -> Green Locators -> Red220.127.116.11.0.0.210.0.0.111.0.0.1
Locator ReachabilityProvider A10.0.0.0/8Provider B18.104.22.168/8ITRITRETRETRProvider Y22.214.171.124/8Provider X126.96.36.199/8PI EID-prefix 188.8.131.52/8Legend: EIDs -> Green Locators -> Red184.108.40.206.0.0.210.0.0.111.0.0.1-> ordinal 0-> ordinal 1loc-reach-bits:0x0000 0003
Changing Mapping EntriesA change is defined to be:Adding a locator to a locator-setChanging an existing locators priority or weight (for either unicast or multicast)Removing a locator from a locator-setAdding entries is simpleAppend to the end, new loc-reach-bit allocated and setOld cachers ignore loc-reach-bit set for non-existent locatorNew cachers use new locator-set and all loc-reach-bits
Changing Mapping EntriesRemoving a locator is done by:Set loc-reach-bit to 0Zero-fill address in slot, set priority 255Old cachers have non-zero slot but dont use locator since loc-reach-bit 0New cachers see empty 255 slot and dont useChanging priority or weightsUse Clock Sweep or SMRs
Changing Mapping EntriesEID-prefix: 220.127.116.11/24, loc-reach-bits: 0x000f, locator-set: 18.104.22.168, priority: 1, weight: 25 22.214.171.124, priority: 1, weight: 25 126.96.36.199, priority: 1, weight: 25 188.8.131.52, priority: 1, weight: 25Changed providers: 184.108.40.206 disconnect and 220.127.116.11 connectsOver time compaction may be requiredto get loc-reach-bits back!
Locator-Set Compaction ChangesOperational MechanismClock SweepProtocol MechanismSolicit Map-Requests (SMRs)
Clock SweeptimeSend Map-Replies with old mapping with TTL = 1 hourSend Map-Replies with old mapping with TTL = 1 minute(not to scale)Send Map-Replies with new mapping with TTL = 24 hours
Solicit Map-Requests (SMRs)Used when a site needs compactionSites solicit Map-Requests from active sitesSMR-bit is in encapsulated LISP headerITRs rate limit to control the number and rate of Map-Requests they want to receiveRemote ITRs rate-limit Map-Requests until they get a Map-Reply with the new database mapping entryNonce from SMR copied to Map-Request copied to Map-ReplyMap-Request can be sent either on ALT or underlying networkLocal ITR keeps track of which site has new versus old mappings for appropriate loc-reach-bit settingNo map versioning requiredRecommendation is to have only one outstanding change
Mixed LocatorsWhat are mixed locators?dr22# sh ip lisp map-cacheLISP IP Mapping Cache for VRF "default" - 1 entries240.23.0.0/24, uptime: 00:00:14, state: complete, last modified: 00:00:14 18.104.22.168, uptime: 00:00:14, state: up, priority/weight: 1/50 22.214.171.124, uptime: 00:00:14, state: up, priority/weight: 1/50
dr22# sh ipv6 lisp map-cacheLISP IPv6 Mapping Cache for VRF "default" - 1 entries0240: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 126.96.36.199, uptime: 00:22:00, state: up, priority/weight: 1/33 188.8.131.52, uptime: 00:22:00, state: up, priority/weight: 1/33
Mixed LocatorsLISP-ALT needs to be dual-stackData Probes and Map-Requests are homogenousEID needs to be in destination addressMap-Reply is sent on the underlying networkTherefore underlying has to be dual-stackBut IPv6 is not ubiquitous so we need IPv4 Map-Replies for IPv6 Data Probes or Map-Requests
Mixed Locators - Some CautionsLocator Reachability tells you that xTR is upDoesnt tell you what the AF path is from you to the ETRHashing considerationsDestination EID hashes to AF RLOCSource RLOC must be same AFSetting priorities for a mixed locator-set is difficultBecause you dont know AF path for requesting source siteBetter to have crossed setsIPv4 EIDs -> all IPv6 RLOCs (China and Japan deployments)IPv6 EIDs -> all IPv4 RLOCs (US deployments)
Mixed Locators are UsefulProvider A10.0.0.0/8Provider B184.108.40.206/8ITRITRETRETRProvider Y220.127.116.11/8Provider X18.104.22.168/822.214.171.124.0.0.210.0.0.111.0.0.1IPv4 InternetIPv6-onlyIPv6-onlyLegend: EIDs -> Green Locators -> Red
Mixed Locators are UsefulProvider A10.0.0.0/8Provider B126.96.36.199/8ITRITRETRETRProvider Y188.8.131.52/813::/16Provider X184.108.40.206/8220.127.116.11.0.0.210.0.0.111.0.0.1Partly Dual-Stack InternetIPv6-onlyDual-stack13::.218.104.22.168Dual-stackLegend: EIDs -> Green Locators -> Red
Spec Diffs between -06 to -08Lots of clarification text from many reviewersClearly specify only 2 LISP headers can be prependedFirst one for Loc/ID split by CPE routerSecond one for TE by ISP routerAdd SMR-bit to data header and Map-RequestSteal a loc-reach-bitSpecify how to select a source UDP port number
Spec Diffs between -06 to -08Added mpriority and mweightSo locator selection can be different for unicast or multicast flowsUpdated section on LISP-Multicast to summarize details in draft-farinacci-lisp-multicast-00.txtWhen ITR receives ICMP unreachableIt may originate one to the source host inside of its siteAdd section on locator hashing for equal-priority locatorsAdd sections for Clock Sweep and SMRsUpdated milestone section
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.
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.
Open IssuesExperiment with more-specific mappings and policy-based Map-Reply priority changing ISP resident TE-xTR functionality with another multi-level LISP hierarchyFirm up details on LISP-MulticastLISP can do some form of mobilityMore specific state only at edges in xTRsCan we extend