Digging through a bunch of half written posts and I found this one I started on LISP about the time Draft v4 came out. I’ve been watching its slow development over the last year and a bit and thought I’d take a stab at what a possible cloud, and cloud computing, application would be.
Keeping in mind that it is a draft standard, and I am working with a limited understanding based on the draft document (to be honest I fall asleep every second paragraph reading this thing each time a new draft is released), and I thought I’d jot down a couple of possible and extrapolated scenarios.
What is it?
Locator/ID separator protocol. (LISP) is a draft protocol that proposes the separation of the an internet facing host address from that of the internet routable address. Edge routers translate and then encapsulate/de-encapsulate packets from their source end-point IDs (EID) to their location (RLOC).
What does all that mean? It simply means that that internet facing routers encapsulate, or tunnel, traffic between each other dynamically (they are able to look up the EID:RLOC mapping and do not require static tunnels/mappings).
This is an overly simplistic overview, however, detailed information on the function of the protocol is available in the draft proposal.
LISP was was created to address a number of things:
- Improve multi-homing (for both service providers and end users);
- through allowing the control of ingress traffic, something that cannot be cleanly done today with BGP,
- allow for provider independent addressing;
- reduce core routing table.
LISP does this, and more, by allowing end devices to be addressed, as chosen by the administrator, and only border/edge internet routers (Egress Tunnel Router – ETR or Ingress Tunnel Router ITR) need the ability to map or translate the Route Location (RLOC) to the End point ID (EID).
Cloud services advantages
With the explosion of *aaS providers and the charge forward on Cloud interoperability standards, having the ability to move or multi-host [*] your computational resources is becoming ever-more enticing. Today there is no simple, cheap and effective solution able to do either as the underlying network building blocks were not originally designed with these tasks in mind.
Some of the things LISP offers are:
- devices with the same EID can co-exist,
- scalable addressing,
- control over traffic flow.
Having the ability to address hosts with the same IP address opens up a simplified way to do a number of things.
It removes the need to re-address hosts when moving them from one provider to another, It removes the need to do weird and wonderful address advertisements through BGP (from conditional advertising to originating your IP address from multiple AS numbers, or splitting your AS). It can even mean the removal of the need for costly global site load balancing (GSLB) infrastructure.
This simplifies options such as:
- DR services,
- Migrate based on cheapest resource, see Amazon Web Services spot pricing.
In the below figure, the source network “blue” can address the devices at the destination network(s) “green” and “red“. With LISP “green” and “red” can be one in the same. Again this is a simplistic overview, where as the underlying mechanics are reasonably complex.
Being able to address your machines once and not have to worry about changing them as you move from in-house to provider and from provider to provider enables a seamless transition for both applications and users, by this I mean functional seamlessness.
LISP offers a scalable addressing format, whereby the site addressing is separate (decoupled) from the provider address space.
The LISP addressing format:
Figure 2: LISP address format
Separating the addressing from each other allows a more scalable addressing scheme, and coupling it with a standard virtualisation format, opens up the ability for the complete modularisation of not only the application but the resource underpinning the virtual machine.
Control over traffic flow
There isn’t a lot to go over here. The idea is to be able to control routes and routing preference as per an IGP (interior gateway protocol). Today routing is preferred through one of several BGP metrics, most of which are either not passed on to the upstream carrier or are ignored, forcing you to either advertise a more specific route (10.0.0.1/32 wins over 10.0.0.0/24) or play with AS prepends. LISP allows EIDs to be advertised with equal, or weighted, metrics from multiple RLOCs.
As this is still in draft there is little to comment on from the protocol point of view. LISP looks to be designed secure. EIDs are securely advertised and Ingress Tunnel Routers (ITRs) will not accept unsolicited connections.
However as always the obvious questions do spring to mind:
- With the ability to advertise the resources available people can effectively see what makes up your environment. <- Security through obscurity, always a poor tactic
- Advertise additional/competing resources
- In a fluid market cheaper or less utilised resources (depending on how this, if ever, gets implemented past Amazon EC2) <- This is an availability issue as opposed to LISP itself.
- advertise the same ranges (both RLOC/EID) to get your traffic. <- Like BGP, if poorly configured it can be exploited.
- de-register you from the database effectively blocking you from your customers/potential customers <- As I’ve not delved into the details of LISP-ALT (one of the mapping database proposals) I see this similar to BGP config issues.
All in all LISP has a lot to offer the internet and expanding market that is cloud computing. I see its adoption being similar to that of IPv6; people understand that it is a good idea and it fixes some of the issues that they have been screaming about, however they are getting by just fine with what they have now. Here in Australia it has taken government mandate of IPv6 for their agencies to get it kick-started, however it still has barely grazed the surface of corporates.
[*] Multi-host – Have instances of your services to support DR or load spike/balancing across multiple *aaS providers.