LISP ITR Graceful Restart

Document Type Expired Internet-Draft (individual)
Last updated 2014-06-23 (latest revision 2013-12-20)
Stream (None)
Intended RFC status (None)
Expired & archived
pdf htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at


The Locator/ID Separation Protocol (LISP) is a map-and-encap mechanism to enable communications between hosts identified with their Endpoint IDentifier (EID) over the Internet where EIDs are not routable. To do so, packets toward EIDs are encapsulated in packets with routing locators (RLOCs) to form dynamic tunnels. An Ingress Tunnel Router (ITR) that encapsulates EID packets determines tunnel endpoints via mappings that associate EIDs to RLOCs. Before encapsulating a packet, the ITR queries the mapping system to obtain the mapping associated to the EID of the packet it must encapsulate. Such mapping is cached by the ITR in its local EID-to-RLOC cache for any subsequent encapsulation for the same EID. LISP is scalable because EID-to-RLOC mappings are cached on ITRs. Initially, the cache is empty and is populated progressively according to the traffic traversing the ITR. However, after an ITR is restarted, e.g., for maintenance reason, its cache is empty which means that all packets that are re-routed to the freshly restarted ITR will cause cache misses and a potentially high loss rate. In this draft, we present mechanisms to reduce the negative impact on traffic caused by the restart of an ITR in a LISP network.


Damien Saucez (
Olivier Bonaventure (
Luigi Iannone (
Clarence Filsfils (

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)