Since morning I was think about the working of LISP and how it can impact the requirement of BGP in enterprise segment, where BGP is used purely for multihoming. With all thanks to Cisco's documentation I am able to find an answer for it.
And the answer is - "YES"
LISP can perform much better than BGP when used for Multihoming, Disaster Recovery and Mobility. Lets have a look how LISP packet goes around in the WAN cloud -
When a host in a LISP-capable domain wants to send a packet, it first
looks up the correspondent host's EID in the DNS. It then puts its EID
in the packet source address, and EID of the correspondent host in its
destination address; if the destination of the packet is in another
domain, the packet traverses the source domain infrastructure to one of
the domain ITRs. If the ITR has cached the EID-to-RLOC mapping for the destination
EID, it sets the destination RLOC in the outer (encapsulated) header to
the cached RLOC, and the source RLOC to its RLOC (note that the inner
header has the source host's EID as the source and the destination's EID
in the Destination field). The packet is then sent over the Internet to
the ETR indicated in the destination RLOC, which decapsulates the
packet and sends it on to the destination EID. If, on the other hand, the ITR does not have a EID-to-RLOC
mapping for the destination EID, it encapsulates the packet in a LISP
header in which the destination address is the same as the inner header
destination address, namely, the EID of the destination host. This
packet is a Data Probe packet, and is routed over the LISP-ALT topology
to the LISP-ALT router (typically an ETR, but this type of router is not
required) that is authoritative for the EID-to-RLOC mapping. When the
ETR receives the Data Probe packet, it decapsulates the packet and sends
it on to the destination EID and sends a Map Reply to the source ITR so
subsequent packets are sent natively over the Internet (as opposed to
over the LISP-ALT overlay network). This query/response transaction is
required only for the first packet sent between sites; all subsequent
packets are sent LISP-encapsulated directly between the ITR and the ETR
(and in particular, not over the LISP-ALT topology). Finally, note that
the ITR could also preload its cache with mappings for popular
destinations using the Map-Request message, avoiding the Data Probe
packet (and associated latency, if any) altogether.
For example, consider the scenario depicted in Figure below. In this case, a source S with EID 1.0.0.1 wants to send a packet to destination D whose EID is 2.0.0.2. The packet arrives at ITR S2, which does not have an EID-to-RLOC mapping for 2.0.0.2. S2 LISP-encapsulates the packet with the outer header having its RLOC (11.0.0.1) as the source address, copies the destination EID (2.0.0.2)
from the inner header to the outer-header destination, and sends the
data packet (a Data Probe) into the LISP-ALT topology. The packet
follows the paths computed by BGP in the LISP-ALT topology to ETR D2.
When D2 receives the packet, it decapsulates it and forwards the packet
to the destination 2.0.0.2; D2 also responds with a Map-Reply message that tells S2 (11.0.0.1) that the EID-to-RLOC mapping for 2.0.0.0/8 has two elements, ETR D1 (whose RLOC is 12.0.0.2) and ETR D2 (whose RLOC is 13.0.0.2).
After receiving the Map Reply, ITR S2 can send LISP-encapsulated
packets natively over the Internet (that is, not over the ALT topology).
Note that the mapping has priority (p) and weight (w) attributes.
Priorities tell the ITR which ETRs to use in which order, and weights
tell the ITR how to split load across ETRs of a given priority (w is a
percentage of traffic that should go to each ETR). In this case, both
ETRs have the same priority (1), and have weight 50 (that is, each ETR
should receive 50 percent of the traffic).
So, what are the benefits when using LISP ?
Okie...
- Protocol Independent - LISP doesn’t care if the EID
or the actual packet payload is IPv4, IPv6 or IPv18 (no it doesn’t
exist yet, but it might!) it just puts a wrapper on the packet and sends
it along.
- Smaller routing table and rapid convergence times -
All of the volatile changes will be at the edges so the RLOCs will stay
mostly the same. There will be few routing entries in the public
networks between RLOCs and little routing churn.
- Inherit Multihoming, Load Balancing and Redundancy -
Because of the LISP-ALT overlay and some new weighting and priority
techniques introduced, there are a lot more options for connecting from
multiple places and what you can do with the traffic between those
networks.
Apart from that configuring & managing a BGP network is always complex and also requires high end devices to operate on, LISP would bring down the TCO for the enterprises.
Cisco Nexus Overlay Transport Virtualization - Read This
Cisco Nexus Fibre Channel over Ethernet - Read This