RFC 7834

Locator/ID Separation Protocol (LISP) Impact

📅 published April 2016, from ietf

Internet Engineering Task Force (IETF) 🎀✨

bestie, okay so this is the title block 💅 (I'm working all the boring stuff in up here so you don't have to scroll):

  • RFC number: 7834 🦋
  • Title: Locator/ID Separation Protocol (LISP) Impact 🌸
  • Authors: D. Saucez (INRIA), L. Iannone (Telecom ParisTech), A. Cabellos and F. Coras (Technical University of Catalonia) 👑
  • Category: Informational 🧚 (so it is NOT a Standards Track spec, it's just here to share knowledge, no cap)
  • ISSN: 2070-1721
  • Date: April 2016 📅
  • Obsoletes / Updates: neither! It doesn't replace or change any other RFC 💖

Also the authors' names are on the byline, so, iconic credit 🙌

Abstract ✨

So the Locator/ID Separation Protocol (LISP) is giving scalability glow-up for Internet routing 💜. It does this by using three big ideas: address role separation, encapsulation, and mapping 🔥. This doc is built from implementation work, real deployment experiences, and theory stuff, and it talks about how deploying LISP can change things for both the routing infrastructure AND the end user 🌈.

Status of This Memo 📜

Okay, lowkey important: this document is not an Internet Standards Track specification 🙈. It's published just for informational purposes 🍓.

It IS a product of the Internet Engineering Task Force (IETF) 🎀, and it represents the consensus of the IETF community ✨. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) 👑. Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 for the deets 💅.

For the current status, errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7834 🦋.

Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved 💖.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were in effect on the date of publication 📜. Please actually read these, bestie, because they explain your rights and restrictions for this document 🫶. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License ⚠️.

Table of Contents 🗺️

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
2.  LISP in a Nutshell  . . . . . . . . . . . . . . . . . . . . .   4
3.  LISP for Scaling the Internet Routing Architecture  . . . . .   5
4.  Beyond Scaling the Internet Routing Architecture  . . . . . .   6
  4.1.  Traffic Engineering . . . . . . . . . . . . . . . . . . .   8
  4.2.  LISP for IPv6 Co-existence  . . . . . . . . . . . . . . .   8
  4.3.  Inter-domain Multicast  . . . . . . . . . . . . . . . . .   9
5.  Impact of LISP on Operations and Business Models  . . . . . .  10
  5.1.  Impact on Non-LISP Traffic and Sites  . . . . . . . . . .  10
  5.2.  Impact on LISP Traffic and Sites  . . . . . . . . . . . .  11
6.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
  7.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
  7.2.  Informative References  . . . . . . . . . . . . . . . . .  14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  17
Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

1. Introduction 🦋

Okay bestie, so LISP runs on those same three principles (address role separation, encapsulation, and mapping) to glow up Internet routing scalability ✨. When it was first invented, the whole goal was fixing the Internet routing scaling problem [RFC4984] 💅. Since then there have been years of implementations and experiments digging into the impact and the open questions of using LISP for inter-domain routing scalability 🔥.

Here's the plot twist: because LISP uses mapping and encapsulation, it can be used for way more than just routing scalability 🌈. For example, LISP gives a LISP site a way to precisely control its inter-domain outgoing and incoming traffic, and you can apply different policies to different domains exchanging traffic with it 👑. LISP can also help ease the move from IPv4 to IPv6, since it lets IPv4 ride over IPv6 or IPv6 ride over IPv4 🧚. And yes, LISP supports inter-domain multicast too 💜.

This doc describes, at a high level, the impacts and open questions still floating around LISP, based on implementation and deployment experience plus research work 🎀. It's super useful for thinking about future approaches and for more experiments that clear up the big open questions (like around operations) 🙈. LISP uses a tunnel-based data plane and a distributed control plane 🦋. It also needs some new functionality, like reachability mechanisms ✨.

LISP is more than just an encapsulation technology, and it's still new 🌸. Until there's even more deployment experience, some open questions about LISP deployment and operations remain 🫶. As an encapsulation technology, there may be concerns about a reduced Maximum Transmission Unit (MTU) size in some deployments ⚠️. A big impact of LISP is on network operations around resiliency and troubleshooting 😭. Because LISP relies on cached mappings and encapsulation, resiliency during failures and troubleshooting may be harder 💀. Encapsulation can also make failure detection and recovery slower, and it needs more coordination than a single, non-encapsulated routing domain solution 🍓.

2. LISP in a Nutshell 🌰

LISP is built on three principles: address role separation, encapsulation, and mapping 💖.

The address space gets split into two sets with different semantic meanings: the Routing Locators (RLOCs) and the Endpoint Identifiers (EIDs) 🦋. RLOCs are addresses that are typically assigned from the Provider Aggregatable (PA) address space 🌸. EIDs are given to nodes in edge networks as a block of contiguous addresses, and those are typically Provider Independent (PI) 👑. To limit the scalability problem, LISP only requires the PA routes toward the RLOCs to be announced in the provider infrastructure 🔥. For non-LISP deployments, on the other hand, the EIDs need to be propagated too 😭.

LISP routers sit at the boundary between the EID and RLOC spaces ✨. Routers that exit the EID space (toward the provider domain) are called Ingress Tunnel Routers (ITRs), and the ones that enter the EID space (from the provider domain) are called Egress Tunnel Routers (ETRs) 🧚. When a host sends a packet to a remote destination, it sends it just like in the non-LISP Internet 💅. The packet reaches the border of its site at an ITR 🎀. Since EIDs aren't routable on the Internet, the packet gets encapsulated with the source address set to the ITR RLOC and the destination address set to the ETR RLOC 🌈. The encapsulated packet then gets forwarded through the provider domain until it reaches the selected ETR 🦋. The ETR de-encapsulates the packet and forwards it to its final destination 💜. The acronym xTR stands for Ingress/Egress Tunnel Router, and it's used for a router playing both roles 🫶.

The correspondence between EIDs and RLOCs is given by the mappings 🗺️. When an ITR needs to find the ETR RLOCs that serve an EID, it queries a mapping system 🔍. With the LISP Canonical Address Format (LCAF) [LISP-LCAF], LISP isn't restricted to the Internet protocol for EID addresses 🌸. With LCAF, any address type can be used as an EID, since the address is only the key for the mapping lookup 💖. For example, LISP can transport Ethernet frames over the Internet 🤯.

An introduction to LISP can be found in [RFC7215] 📚. The LISP specifications are given in [RFC6830], [RFC6833], [LISP-DDT], [RFC6836], [RFC6832], and [RFC6834] 🎀.

Part 1 of 4 is done, bestie! 💖 Say the word and I'll keep going with Section 3 next 🫶

3. LISP for Scaling the Internet Routing Architecture ✨

okay so the original goal of LISP was to make the Internet routing architecture more scalable 💖 It does this with traffic engineering and stub Autonomous System (AS) prefixes, which are no longer announced in the Default-Free Zone (DFZ). The result is routing tables that are smaller and more stable, meaning they experience less churn 🌸 At the edge of the network, the information needed to forward packets (the mappings) is fetched on demand using a pull model. The current Internet BGP model uses a push model instead 🙈 So the scalability of edge networks depends less on the size of the Internet and more on its traffic matrix. Several studies have proven this scaling improvement (more on those below). The research cited here is based on these assumptions:

  • EID-to-RLOC mappings follow the same prefix size as the current BGP routing infrastructure (current PI addresses only);
  • EIDs are used only at the stub ASes, not in the transit ASes; and
  • the RLOCs of an EID prefix are deployed at the edge between the stubs owning the EID prefix and the providers, allocating the RLOCs in a PA mode.

These assumptions line up with [RFC7215] and current LISP deployments 🦋 It's recognized that they may change in the longer term. [KIF13] and [CDLC] explore different EID prefix space sizes and still show results that are consistent and equivalent to the above assumptions, so they're giving strong vibes 🔥

Quoitin et al. [QIdLB07] show that separating the locator and identifier roles at the network level improves routing scalability by reducing the Routing Information Base (RIB) size (up to one order of magnitude). It also increases path diversity, which means better traffic engineering capabilities 👑 [IB07] and [KIF13] show, based on real Internet traffic traces, that the number of mapping entries an ITR must handle in a network with up to 20,000 users is limited to a few tens of thousands. The signaling traffic (Map-Request/Map-Reply packets) is in the same order of magnitude as DNS request/reply traffic. And the encapsulation overhead, while not negligible, is very limited (a few percentage points of the total traffic volume) ✨

Previous studies looked at a timer-based cache eviction policy, where mappings are deleted from the cache when a timeout happens. [CDLC] takes a more general approach based on the Least Recently Used (LRU) eviction policy 💅 It proposes an analytic model for the EID-to-RLOC cache size when prefix-level traffic has a stationary generating process. The model shows that the miss rate can be accurately predicted from the EID-to-RLOC cache size and a small set of easily measurable traffic parameters. The model was validated using four one-day-long packet traces collected at egress points of a campus network and an academic exchange point, with EID prefixes treated as the same size as BGP prefixes. This means operators can provision the EID-to-RLOC cache of their ITRs according to the miss rate they want to achieve for their traffic 🌈

Results in [CDLC] indicate that, for a given target miss ratio, the size of the cache depends only on the parameters of the popularity distribution. It's independent of the number of users (the size of the LISP site) and the number of destinations (the size of the EID prefix space). So if the popularity distribution stays constant, then as the number of users and destinations grows, the cache size needed for a given miss rate stays constant at O(1) 🧚

LISP usually fills its EID-to-RLOC cache in pull mode, which means the ITR retrieves mappings on demand. The big perk is that the EID-to-RLOC cache size only depends on the traffic characteristics at the ITR, and it's independent of the size of the provider domain 💜 The tradeoff is some delay when sending packets that don't hit an entry in the cache (for those, a mapping has to be learned first). That delay is bounded by the time it takes to retrieve the mapping from the mapping system. Also, like a push model (e.g., BGP), the pull model induces signaling messages that correspond to retrieving mappings on a cache miss. The difference is that the signaling load only depends on the traffic at the ITR and isn't triggered by external events the way it is in BGP. [CDLC] shows that the miss rate is a function of the EID-to-RLOC cache size and the traffic generation process. [CDLC], [SDIB08], and [SDIB08] show from traffic traces that, in practice, the cache miss rate, and therefore the signaling rate, stays low 🍓

4. Beyond Scaling the Internet Routing Architecture 🌸

LISP is so much more than a scalability solution 😭 It's also a tool for providing both incoming and outgoing traffic engineering [S11] [LISP-TE], it can be used as an IPv6 transition at the routing level, and it can be used for inter-domain multicast [RFC6831] [LISP-RE]. LISP has also been identified as a way to support devices' Internet mobility [LISP-MN], and to support virtual machines' mobility in data centers and multi-tenant VPNs. The last two uses are not discussed further, since they're out of scope for the current LISP Working Group charter.

A key advantage of the LISP architecture is that it makes routing easier in environments where there's little to no correlation between network endpoints and topological location. In service-provider environments, this is needed for a range of consumer use cases that require an inline anchor to deliver a service to subscribers. Inline anchors provide one of three types of capabilities:

  • enable mobility of subscriber endpoints
  • enable chaining of middlebox functions and services
  • enable functions to be scaled out seamlessly

Without LISP, operators commonly aggregate service anchors in custom-built boxes. That limits deployments: endpoints can only move on the same mobile gateway, functions can only be chained if traffic traverses the same wire or the same Deep Packet Inspection (DPI) box, and capacity can only be scaled out if traffic fans out to or from a specific load balancer 🙄

With LISP, service providers can distribute, virtualize, and instantiate subscriber-service anchors anywhere in the network ✨ Typical use cases for virtualized inline anchors and network functions include Distributed Mobility, Virtualized Evolved Packet Core (vEPC), and Virtualized Customer Premise Equipment (vCPE), where functionality previously anchored at a customer premise is now dynamically allocated in the network. They also include Virtualized SGi LAN, Virtual IP Multimedia Subsystems (IMSs), Virtual Session Border Controller (SBC), and so on 🎀

ConteXtream [ConteXtream] has been deploying map-assisted overlay networks since 2006, first with a proprietary solution and then evolving to standard LISP. The solution has been deployed in production at three tier-1 operators spanning hundreds of millions of subscribers 🤯 Map-assisted overlays were primarily used to map subscriber flows to services resources dynamically, based on profiles and conditions. Specifically, they've been used to map mobile subscribers to value-added/optimization services, broadband subscribers to telephony services, and fixed-mobile subscribers to Broadband Network Gateway (BNG) functions and Internet access services. The LISP map-assisted overlay architecture is used to optimally resolve subscriber to services, functions, instances, and IP overlay aggregation locations on a per-flow basis and just in time 🦋

4.1. Traffic Engineering 💅

In the current (non-LISP) routing infrastructure, addresses used by stub networks are globally routable, and the routing system distributes the routes to reach those stubs. With LISP, the EID prefixes of a LISP site are not routable in the DFZ. Mappings are needed to determine the list of LISP routers to contact to forward packets. This difference is a big deal for two reasons. First, packets aren't forwarded to a site, they're forwarded to a specific router. Second, a site can control its entry points for traffic by controlling its mappings 👑

For traffic engineering purposes, a mapping associates an EID prefix with a list of RLOCs. Each RLOC is annotated with a priority and a weight. When there are several RLOCs, the ITR selects the one with the highest priority and sends the encapsulated packet to that RLOC. If several RLOCs share the highest priority, the traffic is balanced proportionally to their weights among them. So traffic engineering in LISP lets the mapping owner have fine-grained control over the primary and backup paths for its incoming and outgoing packets. It can also share the load among its links 🌈 An example of this is described by Saucez et al. [SDIB08], which shows how to use LISP to direct different types of traffic onto different links with different capacities.

Traffic engineering in LISP goes one step further, because every Map-Request contains the source EID address of the packet that caused a cache miss and triggered the Map-Request. That means a mapping owner can differentiate the answer (Map-Reply) it gives to Map-Requests based on the requester 🧚 This isn't possible with BGP today, because a domain can't exactly control the routes received by domains that aren't in its direct neighborhood 🙈

4.2. LISP for IPv6 Co-existence 🫶

The LISP encapsulation mechanism is designed to support any combination of address families for locators and identifiers. So it's possible to bind IPv6 EIDs with IPv4 RLOCs and vice versa. This allows transporting IPv6 packets over an IPv4 network (or IPv4 packets over an IPv6 network), which makes LISP a valuable mechanism for easing the transition to IPv6 💖

Here's an example: the network infrastructure of a data center is IPv4 only, but dual-stack front-end load balancers are used. In this scenario, LISP can provide IPv6 access to servers even though the network and the servers only support IPv4 🥹 Assuming the data center's ISP offers IPv6 connectivity, the data center only needs to deploy one (or more) xTR(s) at its border with the ISP, and one (or more) xTR(s) directly connected to the load balancers. The xTR(s) at the ISP's border tunnel IPv6 packets over IPv4 to the xTR(s) directly attached to the load balancer. That load balancer's xTR de-encapsulates the packets and forwards them to the load balancer, which acts as a proxy by translating each IPv6 packet into an IPv4 packet. The IPv4 packets are then sent to the appropriate servers. When the server's response arrives at the load balancer, the packet is translated back into an IPv6 packet and forwarded to its xTR(s). Those xTR(s) tunnel it back, over the IPv4-only infrastructure, to an xTR connected to the ISP. The packet is then de-encapsulated and forwarded to the ISP natively in IPv6 🦋

4.3. Inter-domain Multicast 📡✨

okay so LISP has native support for multicast [RFC6831] 💖 bestie, this is so iconic. From the data-plane side, when a multicast-enabled xTR gets an EID-sourced multicast packet, it wraps that packet inside another multicast packet and then sends it along an RLOC-level distribution tree 🌳🦋. So xTRs have to be part of BOTH the EID distribution trees AND the RLOC-level ones 😭🫶. On the control-plane side, group addresses have no topological meaning, so they do NOT need to be mapped 🙈. Also, this is important, LISP-Multicast only works properly if inter-domain multicast is actually available 💀.

Now here's the glow-up for when it isn't 💅 LISP Replication Engineering (LISP-RE) [LISP-RE] [CDM12] uses LISP messages [LISP-MULTI-SIGNALING] to pass out multicast state, so it can build xTR-based inter-domain multicast distribution trees when inter-domain multicast support is missing 🔥. The simulations tested three different management strategies for low-latency content delivery, and they showed these overlays can support thousands of member xTRs, hundreds of thousands of end hosts, and deliver content at latencies close to unicast ones [CDM12] 🤯✨. It was also observed that high client churn has a limited impact on performance and management overhead 🎀.

Similar to LISP-RE, "Signal-Free LISP Multicast" [LISP-SFM] can be used when the core network does not provide multicast support 🌈. The main difference is that instead of using signaling to build inter-domain multicast trees, signal-free only leverages the map server for multicast state storage and distribution 💜. As a result, the source ITR generally does head-end replication, but it might also be used to emulate LISP-RE distribution trees 🧚.

5. Impact of LISP on Operations and Business Models 💼🌸

okay so there are a bunch of implementation efforts ([IOSNXOS], [OpenLISP], [LISPmob], [LISPClick], [LISPcp], and [LISPfritz]) that have been made to assess the specifications 🔍, and interoperability tests [Was09] have been successful too 🙌. There's also a big worldwide deployment in the international lisp4.net testbed, which currently has nodes running at least three different implementations 🌍, and it's going to teach us more operational stuff about LISP 🎓✨.

The following sections split up the impact of LISP on LISP sites versus non-LISP sites 🦋.

5.1. Impact on Non-LISP Traffic and Sites 🙈

LISP has no impact on traffic that has neither a LISP origin nor a LISP destination 💅. BUT LISP can have a significant impact on traffic between a LISP site and a non-LISP site 😬. That traffic has the same issues as LISP-to-LISP traffic, plus extra problems that come from the transition mechanism allowing the LISP site to swap packets with a non-LISP site [RFC6832] [RFC7215] 🫠.

The transition needs proxy tunnel routers (PxTRs) to be set up 🛠️. Proxies cause path stretch (basically, the path gets longer compared to the topological shortest path) and make troubleshooting harder 😩. There are still open questions about PxTRs:

  • Where to deploy PxTRs? Placement in the topology has a big effect on path stretch 📍.
  • How many PxTRs? The number of PxTRs directly affects the load, and also the impact of a PxTR failing on traffic 📉.
  • What part of the EID space? Will all the PxTRs proxy for the whole EID space, or will it be split up between different PxTRs? 🍰
  • Who operates PxTRs? This is a big one 💸. The entities deploying them need to figure out how they'll handle the extra Capital Expenditure (CAPEX) / Operating Expenses (OPEX) that come with PxTRs. And how will traffic be carried with respect to security and privacy? 🔐

A PxTR will also normally advertise in BGP the EID prefix it proxies for 📢. But if proxies are run by different entities, they'll belong to different ASes 🏢. In that case we need to be sure this won't cause Multi-Origin AS (MOAS) issues that could hurt routing 😵. And it's also important to make sure the way EID prefixes get de-aggregated by the proxies stays reasonable, so it doesn't add to BGP scalability issues 📈🙏.

5.2. Impact on LISP Traffic and Sites 🌈

LISP is a protocol built on the map-and-encap paradigm 🗺️. It has the positive impacts we just covered in the sections above, but it also has impacts on operations 👀:

MTU issue: LISP uses encapsulation, so the MTU gets reduced, and that affects potentially all of the traffic 📦. In practice though, on the lisp4.net network, no major MTU issue has been observed 🎉. This is probably because current end-host stacks are well designed to handle the MTU problem 💅✨.

Resiliency issue: The flexibility and control that Locator/ID separation gives you comes at the cost of more complicated reachability detection 🧩. Identifiers aren't directly routable and have to be mapped to locators, but one locator might be unreachable while others are still reachable 😵‍💫. This is a big deal for any tunnel-based solution 🚨. In today's Internet, packets get forwarded independently of the network's border router, so if one border router fails, another can be used 🙌. With LISP, the destination RLOC specifically designates one particular ETR, so if that ETR fails, the traffic gets dropped even though other ETRs are available for the destination site 💔. Another resiliency issue is that mappings are learned on demand 🧠. When an ITR fails, all its traffic gets redirected to other ITRs that might not have the mappings the redirected traffic asked for 😱. Existing studies [SKI12] [SD12] show, based on measurements and traffic traces, that ITR and RLOC failures are infrequent, but when one happens, a critical number of packets can be dropped 📉. Sadly, current LISP resiliency techniques (based on monitoring or probing) aren't fast enough, with failure recovery on the order of a few seconds 🐢. To tackle this, [LISP-PRESERVE] and [LISP-ITR-GRACEFUL] propose techniques based on local failure detection and recovery 🛡️✨.

Middleboxes/filters: Encryption is increasingly common as a response to pervasive monitoring [RFC7258], and LISP gives the option to encrypt traffic between xTRs [LISP-CRYPTO] 🔒. So middleboxes are increasingly likely to be unable to understand encapsulated traffic, which can make them drop legit packets 🚫. LISP also allows triangular or even rectangular routing, so it's hard to keep a correct state even if the middlebox does understand LISP 🌀. Filtering can have problems too, since they may think only one host is generating the traffic (the ITR), as long as it isn't de-encapsulated 🤷‍♀️. To deal with LISP encapsulation, LISP-aware firewalls that inspect inner LISP packets have been proposed [lispfirewall] 🧱💅.

Troubleshooting/debugging: The biggest issue LISP experimentation has shown is how hard troubleshooting is 😭. When something goes wrong in the network, it's hard to pinpoint why, because the operator only has a partial view of the network 🔎. The operator can see what's in its EID-to-RLOC cache/database and can try to get what's potentially elsewhere by querying the Map Resolvers, but the knowledge stays partial 🫤. On top of that, ICMP packets only carry the first few tens of bytes of the original packet, so when an ICMP arrives at the ITR, it might not have enough info for correct troubleshooting 🙃. Deployment in the beta network showed that LISP+ALT [RFC6836] was not easy to maintain and control [CCR13], which explains the migration to LISP-DDT [LISP-DDT], based on a massively distributed and hierarchical approach [CCR13] 🌳👑.

Business/operational related: Iannone et al. [IL10] have shown there are economic incentives to migrate to LISP 💰, but some questions remain 🤔. For example: how will EIDs be allocated so that aggregation, and therefore scalability of the mapping system, is possible? Who will operate the mapping system infrastructure, and for what benefit? What if several operators run different mapping systems? How will they interoperate or share mapping information? 🧐

Reachability: The overhead related to RLOC reachability mechanisms is not known 🌫️.

6. Security Considerations 🔐💀

okay this part is SERIOUS bestie 😤. A thorough security and threat analysis of LISP is done in detail in [RFC7835] 📚. For LISP and other Internet technologies, most threats can be mitigated using Best Current Practices 🛡️, which means careful deployment and configuration (e.g., filter) 🔧, only activating the features that are really necessary in the deployment ✅, and verifying all the information obtained from third parties 👀. Unless gleaning (Section 6 of [RFC6830] and Section 3.1 of [RFC7835]) features are used, the LISP data plane shows the same level of security as other IP-over-IP technologies 🫶. From a security perspective, the control plane is still the critical part of the LISP architecture 🚨. To mitigate threats on the mapping system, authentication SHOULD be used for all control-plane messages 🔑. The current specification defines security mechanisms [RFC6836] [LISP-SEC] that can reduce threats in open network environments 🌐. The LISP specification defines a generic authentication data field for control-plane messages [RFC6836], which could be used for a general authentication mechanism for the LISP control plane while staying backward compatible 🧩💜.

7. References 📚🎀

7.1. Normative References 📚

okay bestie, these are the must-read docs for the whole spec 🫶 they're the foundations everything else is built on, so if you skip these you're gonna be so lost fr

7.2. Informative References 🍓

these ones are the extra-credit reading 🤓 papers, experiments, and project pages that give you the receipts behind the claims. lowkey a whole rabbit hole, so save them for when you're obsessed enough 💅

  • [CCR13] Saucez, D., Iannone, L., and B. Donnet, "A First Measurement Look at the Deployment and Evolution of the Locator/ID Separation Protocol", ACM SIGCOMM Computer Communication Review, Vol. 43, Issue 2, pp. 37-43, DOI 10.1145/2479957.2479963, April 2013. 📊
  • [CDLC] Coras, F., Domingo, J., Lewis, D., and A. Cabellos, "An Analytical Model for Loc/ID Mappings Caches", IEEE/ACM Transactions on Networking, Vol. 24, Issue 1, pp. 506-516, DOI 10.1109/TNET.2014.2373398, February 2014. 🧠
  • [CDM12] Coras, F., Domingo-Pascual, J., Maino, F., Farinacci, D., and A. Cabellos-Aparicio, "Lcast: Software-defined Inter-Domain Multicast", Computer Networks, Vol. 59, pp. 153-170, DOI 10.1016/j.bjp.2013.10.010, February 2014. 🌈
  • [ConteXtream] ConteXtream Software Company, , "SDN and NFV solutions for carrier networks. (Further details on LISP only through private inquiry.)", <http://www.contextream.com>. 🔒
  • [IB07] Iannone, L. and O. Bonaventure, "On the cost of caching locator/ID mappings", in Proceedings of ACM CoNEXT 2007, DOI 0.1145/1364654.1364663, December 2007. 💸
  • [IL10] Iannone, L. and T. Leva, "Modeling the economics of Loc/ID Split for the Future Internet", IOS Press, pp. 11-20, DOI 10.3233/978-1-60750-539-6-11, May 2010. 💰
  • [IOSNXOS] Cisco Systems Inc., "Locator/ID Separation Protocol (LISP)", 2015, <http://lisp4.cisco.com>. 🖥️
  • [KIF13] Kim, J., Iannone, L., and A. Feldmann, "Caching Locator/ID mappings: An experimental scalability analysis and its implications", Computer Networks, Vol. 57, Issue 4, DOI 10.1016/j.comnet.2012.11.007, March 2013. 🧪
  • [LISP-CRYPTO] Farinacci, D. and B. Weis, "LISP Data-Plane Confidentiality", Work in Progress, draft-ietf-lisp-crypto-03, September 2015. 🔐
  • [LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Delegated Database Tree", Work in Progress, draft-ietf-lisp-ddt-03, April 2015. 🌳
  • [LISP-ITR-GRACEFUL] Saucez, D., Bonaventure, O., Iannone, L., and C. Filsfils, "LISP ITR Graceful Restart", Work in Progress, draft-saucez-lisp-itr-graceful-03, December 2013. 🔄
  • [LISP-LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", Work in Progress, draft-ietf-lisp-lcaf-12, September 2015. 🏷️
  • [LISP-MN] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Mobile Node", Work in Progress, draft-meyer-lisp-mn-14, July 2015. 📱
  • [LISP-MULTI-SIGNALING] Farinacci, D. and M. Napierala, "LISP Control-Plane Multicast Signaling", Work in Progress, draft-farinacci-lisp-mr-signaling-06, February 2015. 📣
  • [LISP-PRESERVE] Bonaventure, O., Francois, P., and D. Saucez, "Preserving the reachability of LISP ETRs in case of failures", Work in Progress, draft-bonaventure-lisp-preserve-00, July 2009. 🛟
  • [LISP-RE] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Maino, F., and D. Farinacci, "LISP Replication Engineering", Work in Progress, draft-coras-lisp-re-08, November 2015. 🪞
  • [LISP-SEC] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. Saucez, "LISP-Security (LISP-SEC)", Work in Progress, draft-ietf-lisp-sec-10, October 2015. 🛡️
  • [LISP-SFM] Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", Work in Progress, draft-ietf-lisp-signal-free-multicast-01, April 2016. 🌊
  • [LISP-TE] Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic Engineering Use-Cases", Work in Progress, draft-farinacci-lisp-te-10, September 2015. 🚦
  • [LISPClick] Saucez, D. and V. Nguyen, "LISP-Click: A Click implementation of the Locator/ID Separation Protocol", 1st Symposium on Click Modular Router, November 2009, <http://hdl.handle.net/2078.1/79067>. 🖱️
  • [LISPcp] "LIP6-LISP open source project", 2014, <https://github.com/lip6-lisp>. 🐙
  • [lispfirewall] "LISP and Zone-Based Firewalls Integration and Interoperability", 2014, <http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_data_zbf/configuration/xe-3s/sec-data-zbf-xe-book/sec-zbf-lisp-inner-pac-insp.html>. 🧱
  • [LISPfritz] "Unsere FRITZ!Box-Produkte", 2014, <http://avm.de/produkte/fritzbox/>. 📡
  • [LISPmob] "An open-source LISP implementation for Linux, Android and OpenWRT", 2015, <http://lispmob.org>. 🐧
  • [OpenLISP] "The OpenLISP Project", 2013, <http://www.openlisp.org>. 🔓
  • [QIdLB07] Quoitin, B., Iannone, L., de Launois, C., and O. Bonaventure, "Evaluating the Benefits of the Locator/Identifier Separation", in Proceedings of MobiArch, Article No. 5, DOI 10.1145/1366919.1366926, August 2007. ⚖️
  • [RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report from the IAB Workshop on Routing and Addressing", RFC 4984, DOI 10.17487/RFC4984, September 2007, <http://www.rfc-editor.org/info/rfc4984>. 🗺️
  • [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>. 👀
  • [S11] Saucez, D., "Mechanisms for Interdomain Traffic Engineering with LISP", PhD Thesis, Universite catholique de Louvain, September 2011, <http://hdl.handle.net/2078.1/92231>. 🎓
  • [SD12] Saucez, D. and B. Donnet, "On the Dynamics of Locators in LISP", in Proceedings of IFIP/TC6 Networking, pp. 385-396, DOI 10.1007/978-3-642-30045-5_29, May 2012. 🌀
  • [SDIB08] Saucez, D., Donnet, B., Iannone, L., and O. Bonaventure, "Interdomain Traffic Engineering in a Locator/Identifier Separation Context", in Proceedings of Internet Network Management Workshop, DOI 10.1109/INETMW.2008.4660330, October 2008. 🛣️
  • [SKI12] Saucez, D., Kim, J., Iannone, L., Bonaventure, O., and C. Filsfils, "A Local Approach to Fast Failure Recovery of LISP Ingress Tunnel Routers", in Proceedings of IFIP Networking 2012, pp. 397-408, DOI 10.1007/978-3-642-30045-5_30, May 2012. ⚡
  • [Was09] Wasserman, M., "LISP Interoperability Testing", IETF 76, LISP WG Presentation, November 2009. 🤝

Acknowledgments 🫶

big thank-yous to Deborah Brungard, Ben Campbell, Spencer Dawkins, Stephen Farrel, Wassim Haddad, Kathleen Moriarty, and Hilarie Orman for reviewing this doc so thoroughly, and for all the comments and suggestions 🥹💖

the people who contributed to this document are Alia Atlas, Sharon Barkai, Ron Bonica, Ross Callon, Vince Fuller, Joel Halpern, Terry Manderson, and Gregg Schudel 👑✨

and the work of Luigi Iannone was partially supported by the ANR 13 INFR 0009 LISP-Lab Project, which you can check out at <http://www.lisp-lab.org> 🌸

Authors' Addresses 📮

Damien Saucez
INRIA
2004 route des Lucioles BP 93
06902 Sophia Antipolis Cedex
France

Email: damien.saucez@inria.fr


Luigi Iannone
Telecom ParisTech
23, Avenue d'Italie, CS 51327
75214 Paris Cedex 13
France

Email: ggx@gigix.net


Albert Cabellos
Technical University of Catalonia
C/Jordi Girona, s/n
08034 Barcelona
Spain

Email: acabello@ac.upc.edu


Florin Coras
Technical University of Catalonia
C/Jordi Girona, s/n
08034 Barcelona
Spain

Email: fcoras@ac.upc.edu

the end of the spec, bestie 🌈💅 you made it through the whole thing!!

📦 where this page comes from