Locator / ID Separation Protocol (LISP) - How soon would you like to see it deployed?

Level of indirection via an IP-in-IP encapsulation, how badly do we need LISP?

No, this post is not about the LISP programming language... it's rather about the locator/id separation protocol proposed by four Cisco engineers at the IETF forum for "Experimental" track couple of years ago! Excerpt from their IETF draft, that defines it: " This draft describes a simple, incremental, network-based protocol to implement separation of Internet addresses into Endpoint Identifiers (EIDs) and Routing Locators (RLOCs). This mechanism requires no changes to host stacks and no major changes to existing database infrastructures. The proposed protocol can be implemented in a relatively small number of routers." LISP provides a level of indirection via IP-in-IP encapsulation that has the potential to solve multitude of problems faced by the Internet (esp. large SP) and its users (esp. large Enterprise), by de-coupling the addressing from underlying topology. So, in essence, topology follows addressing with LISP deployed rather than addressing following topology which creates operational headaches - think multi-homed Enterprise. LISP operations can be divided into control and data plane portions: Control plane: - Mapping Cache, and database (ALT, EMACs etc.) - Mapping Server and Resolver (interfacing LISP sits to mapping database) Data Plane: - IP-in-IP with UDP (LISP) encapsulation - data triggered mapping queries/registrations LISP roles can be divided into: ITR/ETR: Ingress/Egress Tunnel Router (aka xTR) PTR : Proxy Tunnel Router MS/MR: Map Server and Resolver LISP-ALT routers/boxes: BGP and GRE tunnels Overlay On the face of it, it has the potential to solve a ton of problems, and AFAICT, this is one of the most practical solution that I've seen to date for the problem as hinted above and outlined below: - Ease of multi-homing for Enterprises (head-end or branch offices) (a lot better control over ingress traffic without advertising /32s and traffic split egress) - Same goes for ISPs, they can control ingress a lot better - Scales routing table in the Internet (RLOCs only) - Avoid site re-addressing when moving providers - Data Center Virtual Machine mobility (see Microsoft VL2 and Monsoon proposals) - Connecting IPv6 only sites to IPv4 Internet Now to balance the perspective, skeptics seems to focus on: - extra encapsulation overhead and complexity (routing overlay) - LISP's deployment beyond experiment (although openLISP initiative exists for open source implementation) - if this can be a viable solution given the profound impact it will have if adopted on how Internet works today OK, now, I'm looking for some interesting dialog here, please provide your comments, questions, concerns -- i'd be most interested in knowing about why, how, and when you plan to deploy LISP!! Reference: http://tools.ietf.org/html/draft-farinacci-lisp-12 http://www.ietf.org/dyn/wg/charter/lisp-charter.html

Join the Network World communities on Facebook and LinkedIn to comment on topics that are top of mind.

Copyright © 2009 IDG Communications, Inc.

SD-WAN buyers guide: Key questions to ask vendors (and yourself)