1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
|
<pre>Internet Engineering Task Force (IETF) D. Saucez
Request for Comments: 7834 INRIA
Category: Informational L. Iannone
ISSN: 2070-1721 Telecom ParisTech
A. Cabellos
F. Coras
Technical University of Catalonia
April 2016
<span class="h1">Locator/ID Separation Protocol (LISP) Impact</span>
Abstract
The Locator/ID Separation Protocol (LISP) aims to improve the
Internet routing scalability properties by leveraging three
principles: address role separation, encapsulation, and mapping. In
this document, based on implementation work, deployment experiences,
and theoretical studies, we discuss the impact that the deployment of
LISP can have on both the routing infrastructure and the end user.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for informational purposes.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are a candidate for any level of Internet
Standard; see <a href="./rfc5741#section-2">Section 2 of RFC 5741</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7834">http://www.rfc-editor.org/info/rfc7834</a>.
<span class="grey">Saucez, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7834">RFC 7834</a> LISP Impact April 2016</span>
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. LISP in a Nutshell . . . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3">3</a>. LISP for Scaling the Internet Routing Architecture . . . . . <a href="#page-5">5</a>
<a href="#section-4">4</a>. Beyond Scaling the Internet Routing Architecture . . . . . . <a href="#page-6">6</a>
<a href="#section-4.1">4.1</a>. Traffic Engineering . . . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.2">4.2</a>. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-4.3">4.3</a>. Inter-domain Multicast . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5">5</a>. Impact of LISP on Operations and Business Models . . . . . . <a href="#page-10">10</a>
<a href="#section-5.1">5.1</a>. Impact on Non-LISP Traffic and Sites . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.2">5.2</a>. Impact on LISP Traffic and Sites . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-6">6</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-7">7</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7.1">7.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-7.2">7.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-17">17</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<span class="grey">Saucez, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7834">RFC 7834</a> LISP Impact April 2016</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The Locator/ID Separation Protocol (LISP) relies on three principles
to improve the scalability properties of Internet routing: address
role separation, encapsulation, and mapping. When invented, LISP was
targeted at solving the Internet routing scaling problem [<a href="./rfc4984" title=""Report from the IAB Workshop on Routing and Addressing"">RFC4984</a>].
There have now been years of implementations and experiments
examining the impact and open questions of using LISP to improve
inter-domain routing scalability. Experience has shown that because
LISP utilizes mapping and encapsulation technologies, it can be
deployed and used for purposes that go beyond routing scalability.
For example, LISP provides a mean for a LISP site to precisely
control its inter-domain outgoing and incoming traffic, with the
possibility to apply different policies to different domains
exchanging traffic with it. LISP can also be used to ease the
transition from IPv4 to IPv6 as it allows the transport of IPv4 over
IPv6 or IPv6 over IPv4. Furthermore, LISP also supports inter-domain
multicast.
Leveraging implementation and deployment experience, as well as
research work, this document describes, at a high level, the impacts
and open questions still seen in LISP. This information is
particularly useful for considering future approaches and to support
further experimentation to clarify some large open questions (e.g.,
around the operations). LISP utilizes a tunnel-based data plane and
a distributed control plane. LISP requires some new functionalities,
such as reachability mechanisms. Because LISP is more than a simple
encapsulation technology and is a new technology, until even more
deployment experience is gained, some open questions related to LISP
deployment and operations remain. As an encapsulation technology,
there may be concerns on reduced Maximum Transmission Unit (MTU) size
in some deployments. An important impact of LISP is on network
operations related to resiliency and troubleshooting. As LISP relies
on cached mappings and on encapsulation, resiliency during failures
and troubleshooting may be more difficult. Also, the use of
encapsulation may make failure detection and recovery slower, and it
will require more coordination than with a single, non-encapsulated,
routing domain solution.
<span class="grey">Saucez, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7834">RFC 7834</a> LISP Impact April 2016</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. LISP in a Nutshell</span>
LISP relies on three principles: address role separation,
encapsulation, and mapping.
The address space is divided into two sets that have different
semantic meanings: the Routing Locators (RLOCs) and the Endpoint
Identifiers (EIDs). RLOCs are addresses typically assigned from the
Provider Aggregatable (PA) address space. The EIDs are attributed to
the nodes in the edge networks, by a block of contiguous addresses,
which are typically Provider Independent (PI). To limit the
scalability problem, LISP only requires the PA routes towards the
RLOCs to be announced in the provider infrastructure. Whereas for
non-LISP deployments, the EIDs need to be propagated as well.
LISP routers are used at the boundary between the EID and the RLOC
spaces. Routers used to exit the EID space (towards the provider
domain) are called Ingress Tunnel Routers (ITRs), and those used to
enter the EID space (from the provider domain) are called the Egress
Tunnel Routers (ETRs). When a host sends a packet to a remote
destination, it sends it as in the non-LISP Internet. The packet
arrives at the border of its site at an ITR. Because EIDs are not
routable on the Internet, the packet is encapsulated with the source
address set to the ITR RLOC and the destination address set to the
ETR RLOC. The encapsulated packet is then forwarded in 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 is used for a router
playing these two roles.
The correspondence between EIDs and RLOCs is given by the mappings.
When an ITR needs to find ETR RLOCs that serve an EID, it queries a
mapping system. With the LISP Canonical Address Format (LCAF)
[<a href="#ref-LISP-LCAF">LISP-LCAF</a>], LISP is not restricted to the Internet protocol for the
EID addresses. With LCAF, any address type can be used as EID (the
address is only the key for the mapping lookup). LISP can transport,
for example, Ethernet frames over the Internet.
An introduction to LISP can be found in [<a href="./rfc7215" title=""Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations"">RFC7215</a>]. The LISP
specifications are given in [<a href="./rfc6830" title=""The Locator/ID Separation Protocol (LISP)"">RFC6830</a>], [<a href="./rfc6833" title=""Locator/ID Separation Protocol (LISP) Map-Server Interface"">RFC6833</a>], [<a href="#ref-LISP-DDT" title=""LISP Delegated Database Tree"">LISP-DDT</a>],
[<a href="./rfc6836" title=""Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)"">RFC6836</a>], [<a href="./rfc6832" title=""Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites"">RFC6832</a>], and [<a href="./rfc6834" title=""Locator/ID Separation Protocol (LISP) Map-Versioning"">RFC6834</a>].
<span class="grey">Saucez, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7834">RFC 7834</a> LISP Impact April 2016</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. LISP for Scaling the Internet Routing Architecture</span>
The original goal of LISP was to improve the scalability properties
of the Internet routing architecture. LISP utilizes traffic
engineering and stub Autonomous System (AS) prefixes (not announced
anymore in the Default-Free Zone (DFZ)), so that routing tables are
smaller and more stable (i.e., they experience less churn).
Furthermore, at the edge of the network, information necessary to
forward packets (i.e., the mappings) is obtained on demand using a
pull model (whereas the current Internet BGP model uses a push
model). Therefore, the scalability of edge networks is less
dependent on the Internet's size and more related to its traffic
matrix. This scaling improvement has been proven by several studies
(see below). The research studies cited hereafter are based on the
following assumptions:
o EID-to-RLOC mappings follow the same prefix size as the current
BGP routing infrastructure (current PI addresses only);
o EIDs are used only at the stub ASes, not in the transit ASes; and
o 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.
The above assumptions are inline with [<a href="./rfc7215" title=""Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations"">RFC7215</a>] and current LISP
deployments. It is recognized these assumptions may change in the
longer term. [<a href="#ref-KIF13" title=""Caching Locator/ID mappings: An experimental scalability analysis and its implications"">KIF13</a>] and [<a href="#ref-CDLC" title=""An Analytical Model for Loc/ID Mappings Caches"">CDLC</a>] explore different EID prefix space
sizes and still show results that are consistent and equivalent to
the above assumptions.
Quoitin et al. [<a href="#ref-QIdLB07" title=""Evaluating the Benefits of the Locator/ Identifier Separation"">QIdLB07</a>] show that the separation between locator and
identifier roles at the network level improves the routing
scalability by reducing the Routing Information Base (RIB) size (up
to one order of magnitude) and increases path diversity and thus the
traffic engineering capabilities. [<a href="#ref-IB07" title=""On the cost of caching locator/ID mappings"">IB07</a>] and [<a href="#ref-KIF13" title=""Caching Locator/ID mappings: An experimental scalability analysis and its implications"">KIF13</a>] show, based on
real Internet traffic traces, that the number of mapping entries that
must be handled by an ITR of a network with up to 20,000 users is
limited to few tens of thousands; the signaling traffic (i.e.,
Map-Request/Map-Reply packets) is in the same order of magnitude
similar to DNS request/reply traffic; and the encapsulation overhead,
while not negligible, is very limited (in the order of few percentage
points of the total traffic volume).
Previous studies consider the case of a timer-based cache eviction
policy (i.e., mappings are deleted from the cache upon timeout),
while [<a href="#ref-CDLC" title=""An Analytical Model for Loc/ID Mappings Caches"">CDLC</a>] has a more general approach based on the Least Recently
Used (LRU) eviction policy, proposing an analytic model for the EID-
<span class="grey">Saucez, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7834">RFC 7834</a> LISP Impact April 2016</span>
to-RLOC cache size when prefix-level traffic has a stationary
generating process. The model shows that 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 considering EID prefixes as
being of the same size as BGP prefixes. Consequently, operators can
provision the EID-to-RLOC cache of their ITRs according to the miss
rate they want to achieve for their given traffic.
Results in [<a href="#ref-CDLC" title=""An Analytical Model for Loc/ID Mappings Caches"">CDLC</a>] indicate that for a given target miss ratio, the
size of the cache depends only on the parameters of the popularity
distribution; the size of the cache is independent of the number of
users (the size of the LISP site) and the number of destinations (the
size of the EID prefix space). Assuming that the popularity
distribution remains constant, this means that as the number of users
and the number of destinations grow, the cache size needed to obtain
a given miss rate remains constant O(1).
LISP usually populates its EID-to-RLOC cache in a pull mode, which
means that mappings are retrieved on demand by the ITR. The main
advantage of this mode is that the EID-to-RLOC cache size only
depends on the traffic characteristics at the ITR and is independent
of the size of the provider domain. This benefit comes at the cost
of some delay to transmit the packets that do not hit an entry in the
cache (for which a mapping has to be learned). This delay is bound
by the time necessary to retrieve the mapping from the mapping
system. Moreover, similarly to a push model (e.g., BGP), the pull
model induces signaling messages that correspond to the retrieval of
mappings upon cache miss. The difference being that the signaling
load only depends on the traffic at the ITR and is not triggered by
external events such as in BGP. [<a href="#ref-CDLC" title=""An Analytical Model for Loc/ID Mappings Caches"">CDLC</a>] shows that the miss rate is a
function of the EID-to-RLOC cache size and traffic generation
process, and [<a href="#ref-CDLC" title=""An Analytical Model for Loc/ID Mappings Caches"">CDLC</a>], [<a href="#ref-SDIB08" title=""Interdomain Traffic Engineering in a Locator/Identifier Separation Context"">SDIB08</a>], and [<a href="#ref-SDIB08" title=""Interdomain Traffic Engineering in a Locator/Identifier Separation Context"">SDIB08</a>] show from traffic traces
that, in practice, the cache miss rate, and thus the signaling rate,
remain low.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Beyond Scaling the Internet Routing Architecture</span>
LISP is more than just a scalability solution; it is also a tool to
provide both incoming and outgoing traffic engineering [<a href="#ref-S11" title=""Mechanisms for Interdomain Traffic Engineering with LISP"">S11</a>]
[<a href="#ref-LISP-TE" title=""LISP Traffic Engineering Use-Cases"">LISP-TE</a>], it can be used as an IPv6 transition at the routing level,
and it can be used for inter-domain multicast [<a href="./rfc6831" title=""The Locator/ID Separation Protocol (LISP) for Multicast Environments"">RFC6831</a>] [<a href="#ref-LISP-RE" title=""LISP Replication Engineering"">LISP-RE</a>].
Also, LISP has been identified for use to support devices' Internet
mobility [<a href="#ref-LISP-MN" title=""LISP Mobile Node"">LISP-MN</a>] and to support virtual machines' mobility in data
centers and multi-tenant VPNs. These last two uses are not discussed
further as they are out of the scope of the current LISP Working
Group charter.
<span class="grey">Saucez, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7834">RFC 7834</a> LISP Impact April 2016</span>
A key advantage of the LISP architecture is that it facilitates
routing in environments where there is little to no correlation
between network endpoints and topological location. In service-
provider environments, this application is needed in 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:
o enable mobility of subscriber endpoints
o enable chaining of middlebox functions and services
o enable functions to be scaled out seamlessly
Without LISP, the approach commonly used by operators is to aggregate
service anchors in custom-built boxes. This limits deployments as
endpoints can only move on the same mobile gateway, functions can be
chained only if traffic traverses the same wire or the same Deep
Packet Inspection (DPI) box, and capacity can be scaled out only if
traffic fans out to/from a specific load balancer.
With LISP, service providers are able to distribute, virtualize, and
instantiate subscriber-service anchors anywhere in the network.
Typical use cases for virtualized inline anchors and network
functions include Distributed Mobility and Virtualized Evolved Packet
Core (vEPC), Virtualized Customer Premise Equipment (vCPE), where
functionality previously anchored at a customer premise is now
dynamically allocated in the network, Virtualized SGi LAN, Virtual IP
Multimedia Subsystems (IMSs), Virtual Session Border Controller
(SBC), etc.
ConteXtream [<a href="#ref-ConteXtream">ConteXtream</a>] has been deploying map-assisted overlay
networks since 2006, first with a proprietary solution, then evolving
to standard LISP. The solution has been deployed in production in
three tier-1 operators spanning hundreds of millions of subscribers.
Map-assisted overlays had been primarily used to map subscriber flows
to services resources dynamically based on profiles and conditions.
Specifically, it has 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.
<span class="grey">Saucez, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7834">RFC 7834</a> LISP Impact April 2016</span>
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Traffic Engineering</span>
In the current (non-LISP) routing infrastructure, addresses used by
stub networks are globally routable, and the routing system
distributes the routes to reach these stubs. With LISP, the EID
prefixes of a LISP site are not routable in the DFZ; mappings are
needed in order to determine the list of LISP routers to contact to
forward packets. This difference is significant for two reasons.
First, packets are not forwarded to a site but to a specific router.
Second, a site can control the entry points for its traffic by
controlling its mappings.
For traffic engineering purposes, a mapping associates an EID prefix
to 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 this RLOC.
If several RLOCs with the highest priority exist, then the traffic is
balanced proportionally to their weight among such RLOCs. Traffic
engineering in LISP thus allows the mapping owner to have a fine-
grained control on the primary and backup path for its incoming and
outgoing packet use. In addition, it can share the load among its
links. An example of the use of such a feature is described by
Saucez et al. [<a href="#ref-SDIB08" title=""Interdomain Traffic Engineering in a Locator/Identifier Separation Context"">SDIB08</a>], which shows how to use LISP to direct
different types of traffic on different links having different
capacity.
Traffic engineering in LISP goes one step further, as every Map-
Request contains the source EID address of the packet that caused a
cache miss and triggered the Map-Request. It is thus possible for a
mapping owner to differentiate the answer (Map-Reply) it gives to
Map-Requests based on the requester. This functionality is not
available today with BGP because a domain cannot control exactly the
routes that will be received by domains that are not in the direct
neighborhood.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. LISP for IPv6 Co-existence</span>
The LISP encapsulation mechanism is designed to support any
combination of address families for locators and identifiers. It is
then 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), making LISP a valuable mechanism to
ease the transition to IPv6.
An example is the case of the network infrastructure of a data center
being IPv4 only while dual-stack front-end load balancers are used.
In this scenario, LISP can be used to provide IPv6 access to servers
even though the network and the servers only support IPv4. Assuming
<span class="grey">Saucez, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7834">RFC 7834</a> LISP Impact April 2016</span>
that 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 tunnels IPv6 packets over IPv4 to the
xTR(s) directly attached to the load balancer. The load balancer's
xTR de-encapsulates the packets and forwards them to the load
balancer, which act as a proxy, translating each IPv6 packet into an
IPv4 packet. IPv4 packets are then sent to the appropriate servers.
Similarly, 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), which in turn will 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.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. Inter-domain Multicast</span>
LISP has native support for multicast [<a href="./rfc6831" title=""The Locator/ID Separation Protocol (LISP) for Multicast Environments"">RFC6831</a>]. From the data-plane
perspective, at a multicast-enabled xTR, an EID-sourced multicast
packet is encapsulated in another multicast packet and subsequently
forwarded in an RLOC-level distribution tree. Therefore, xTRs must
participate in both EID and RLOC-level distribution trees. Control-
plane wise, since group addresses have no topological significance,
they need not be mapped. It is worth noting that, to properly
function, LISP-Multicast requires that inter-domain multicast be
available.
LISP Replication Engineering (LISP-RE) [<a href="#ref-LISP-RE" title=""LISP Replication Engineering"">LISP-RE</a>] [<a href="#ref-CDM12" title=""Lcast: Software-defined Inter- Domain Multicast"">CDM12</a>] leverages
LISP messages [<a href="#ref-LISP-MULTI-SIGNALING">LISP-MULTI-SIGNALING</a>] for multicast state distribution
to construct xTR-based inter-domain multicast distribution trees when
inter-domain multicast support is not available. Simulations of
three different management strategies for low-latency content
delivery show that such overlays can support thousands of member
xTRs, support hundreds of thousands of end hosts, and deliver content
at latencies close to unicast ones [<a href="#ref-CDM12" title=""Lcast: Software-defined Inter- Domain Multicast"">CDM12</a>]. 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" [<a href="#ref-LISP-SFM" title=""Signal-Free LISP Multicast"">LISP-SFM</a>] can be
used when the core network does not provide multicast support. But
instead of using signaling to build inter-domain multicast trees,
signal-free exclusively leverages the map server for multicast state
storage and distribution. As a result, the source ITR generally
performs head-end replication, but it might also be used to emulate
LISP-RE distribution trees.
<span class="grey">Saucez, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7834">RFC 7834</a> LISP Impact April 2016</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Impact of LISP on Operations and Business Models</span>
Numerous implementation efforts ([<a href="#ref-IOSNXOS" title=""Locator/ID Separation Protocol (LISP)"">IOSNXOS</a>], [<a href="#ref-OpenLISP" title=""The OpenLISP Project"">OpenLISP</a>], [<a href="#ref-LISPmob" title=""An open-source LISP implementation for Linux, Android and OpenWRT"">LISPmob</a>],
[<a href="#ref-LISPClick">LISPClick</a>], [<a href="#ref-LISPcp" title=""LIP6-LISP open source project"">LISPcp</a>], and [<a href="#ref-LISPfritz">LISPfritz</a>]) have been made to assess the
specifications, and additionally, interoperability tests [<a href="#ref-Was09" title=""LISP Interoperability Testing"">Was09</a>] have
been successful. A worldwide large deployment in the international
lisp4.net testbed, which is currently composed of nodes running at
least three different implementations, will allow us to learn further
operational aspects related to LISP.
The following sections distinguish the impact of LISP on LISP sites
from the impact on non-LISP sites.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Impact on Non-LISP Traffic and Sites</span>
LISP has no impact on traffic that has neither LISP origin nor LISP
destination. However, LISP can have a significant impact on traffic
between a LISP site and a non-LISP site. Traffic between a non-LISP
site and a LISP site is subject to the same issues as those observed
for LISP-to-LISP traffic but also has issues specific to the
transition mechanism that allow the LISP site to exchange packets
with a non-LISP site [<a href="./rfc6832" title=""Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites"">RFC6832</a>] [<a href="./rfc7215" title=""Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations"">RFC7215</a>].
The transition requires setup of proxy tunnel routers (PxTRs).
Proxies cause what is referred to as path stretch (i.e., a
lengthening of the path compared to the topological shortest path)
and make troubleshooting harder. There are still questions related
to PxTRs that need to be answered:
o Where to deploy PxTRs? The placement in the topology has an
important impact on the path stretch.
o How many PxTRs? The number of PxTRs has a direct impact on the
load and the impact of the failure of a PxTR on the traffic.
o What part of the EID space? Will all the PxTRs be proxies for the
whole EID space, or will it be segmented between different PxTRs?
o Who operates PxTRs? An important question to answer is related to
the entities that will deploy PxTRs: how will they manage their
additional Capital Expenditure (CAPEX) / Operating Expenses (OPEX)
associated with PxTRs? How will the traffic be carried with
respect to security and privacy?
A PxTR will also normally advertise in BGP the EID prefix for which
they are proxies. However, if proxies are managed by different
entities, they will belong to different ASes. In this case, we need
to be sure that this will not cause Multi-Origin AS (MOAS) issues
<span class="grey">Saucez, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7834">RFC 7834</a> LISP Impact April 2016</span>
that could negatively influence routing. Moreover, it is important
to ensure that the way EID prefixes will be de-aggregated by the
proxies will remain reasonable so as not to contribute to BGP
scalability issues.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Impact on LISP Traffic and Sites</span>
LISP is a protocol based on the map-and-encap paradigm, which has the
positive impacts that we have summarized in the above sections.
However, LISP also has impacts on operations:
MTU issue: As LISP uses encapsulation, the MTU is reduced; this has
implications on potentially all of the traffic. However, in
practice, on the lisp4.net network, no major issue due to the MTU
has been observed. This is probably due to the fact that current
end-host stacks are well designed to deal with the problem of MTU.
Resiliency issue: The advantage of flexibility and control offered
by the Locator/ID separation comes at the cost of increasing the
complexity of the reachability detection. Indeed, identifiers are
not directly routable and have to be mapped to locators, but a
locator may be unreachable while others are still reachable. This
is an important problem for any tunnel-based solution. In the
current Internet, packets are forwarded independently of the
border router of the network meaning that, in case of the failure
of a border router, another one can be used. With LISP, the
destination RLOC specifically designates one particular ETR;
hence, if this ETR fails, the traffic is dropped, even though
other ETRs are available for the destination site. Another
resiliency issue is linked to the fact that mappings are learned
on demand. When an ITR fails, all its traffic is redirected to
other ITRs that might not have the mappings requested by the
redirected traffic. Existing studies [<a href="#ref-SKI12" title=""A Local Approach to Fast Failure Recovery of LISP Ingress Tunnel Routers"">SKI12</a>] [<a href="#ref-SD12" title=""On the Dynamics of Locators in LISP"">SD12</a>] show, based
on measurements and traffic traces, that failure of ITRs and RLOC
are infrequent but that when such failure happens, a critical
number of packets can be dropped. Unfortunately, the current
techniques for LISP resiliency, based on monitoring or probing,
are not rapid enough (failure recovery on the order of a few
seconds). To tackle this issue, [<a href="#ref-LISP-PRESERVE">LISP-PRESERVE</a>] and
[<a href="#ref-LISP-ITR-GRACEFUL">LISP-ITR-GRACEFUL</a>] propose techniques based on local failure
detection and recovery.
Middleboxes/filters: Because of the increasingly common use of
encryption as a response to pervasive monitoring [<a href="./rfc7258" title=""Pervasive Monitoring Is an Attack"">RFC7258</a>] with
LISP providing the option to encrypt traffic between xTRs
[<a href="#ref-LISP-CRYPTO">LISP-CRYPTO</a>], middleboxes are increasingly likely to be unable to
understand encapsulated traffic, which can cause them to drop
legitimate packets. In addition, LISP allows triangular or even
<span class="grey">Saucez, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7834">RFC 7834</a> LISP Impact April 2016</span>
rectangular routing, so it is difficult to maintain a correct
state even if the middlebox understands LISP. Finally, filtering
may also have problems because they may think only one host is
generating the traffic (the ITR), as long as it is not
de-encapsulated. To deal with LISP encapsulation, LISP-aware
firewalls that inspect inner LISP packets are proposed
[<a href="#ref-lispfirewall">lispfirewall</a>].
Troubleshooting/debugging: The major issue that LISP experimentation
has shown is the difficulty of troubleshooting. When there is a
problem in the network, it is hard to pinpoint the reason as the
operator only has a partial view of the network. The operator can
see what is in its EID-to-RLOC cache/database and can try to
obtain what is potentially elsewhere by querying the Map
Resolvers, but the knowledge remains partial. On top of that,
ICMP packets only carry the first few tens of bytes of the
original packet, which means that when an ICMP arrives at the ITR,
it might not contain enough information to allow correct
troubleshooting. Deployment in the beta network has shown that
LISP+ALT [<a href="./rfc6836" title=""Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)"">RFC6836</a>] was not easy to maintain and control [<a href="#ref-CCR13" title=""A First Measurement Look at the Deployment and Evolution of the Locator/ID Separation Protocol"">CCR13</a>],
which explains the migration to LISP-DDT [<a href="#ref-LISP-DDT" title=""LISP Delegated Database Tree"">LISP-DDT</a>], based on a
massively distributed and hierarchical approach [<a href="#ref-CCR13" title=""A First Measurement Look at the Deployment and Evolution of the Locator/ID Separation Protocol"">CCR13</a>].
Business/operational related: Iannone et al. [<a href="#ref-IL10" title=""Modeling the economics of Loc/ID Split for the Future Internet"">IL10</a>] have shown that
there are economical incentives to migrate to LISP; however, some
questions remain. For example, how will the EIDs be allocated to
allow aggregation and hence scalability of the mapping system?
Who will operate the mapping system infrastructure and for what
benefits? 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.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Security Considerations</span>
A thorough security and threat analysis of LISP is carried out in
detail in [<a href="./rfc7835" title=""Locator/ID Separation Protocol (LISP) Threat Analysis"">RFC7835</a>]. For LISP and other Internet technologies, most
of the threats can be mitigated using Best Current Practices, meaning
with careful deployment and configuration (e.g., filter), by
activating only features that are really necessary in the deployment,
and by verifying all the information obtained from third parties.
Unless gleaning (<a href="./rfc6830#section-6">Section 6 of [RFC6830]</a> and <a href="./rfc7835#section-3.1">Section 3.1 of [RFC7835]</a>)
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 remains the critical part of the LISP
architecture. To mitigate the threats on the mapping system,
authentication should be used for all control-plane messages. The
<span class="grey">Saucez, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7834">RFC 7834</a> LISP Impact April 2016</span>
current specification defines security mechanisms [<a href="./rfc6836" title=""Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)"">RFC6836</a>]
[<a href="#ref-LISP-SEC" title=""LISP-Security (LISP-SEC)"">LISP-SEC</a>] that can reduce threats in open network environments. The
LISP specification defines a generic authentication data field for
control-plane messages [<a href="./rfc6836" title=""Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)"">RFC6836</a>], which could be used for a general
authentication mechanism for the LISP control plane while staying
backward compatible.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. References</span>
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Normative References</span>
[<a id="ref-RFC6830">RFC6830</a>] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", <a href="./rfc6830">RFC 6830</a>,
DOI 10.17487/RFC6830, January 2013,
<<a href="http://www.rfc-editor.org/info/rfc6830">http://www.rfc-editor.org/info/rfc6830</a>>.
[<a id="ref-RFC6831">RFC6831</a>] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
Locator/ID Separation Protocol (LISP) for Multicast
Environments", <a href="./rfc6831">RFC 6831</a>, DOI 10.17487/RFC6831, January
2013, <<a href="http://www.rfc-editor.org/info/rfc6831">http://www.rfc-editor.org/info/rfc6831</a>>.
[<a id="ref-RFC6832">RFC6832</a>] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", <a href="./rfc6832">RFC 6832</a>,
DOI 10.17487/RFC6832, January 2013,
<<a href="http://www.rfc-editor.org/info/rfc6832">http://www.rfc-editor.org/info/rfc6832</a>>.
[<a id="ref-RFC6833">RFC6833</a>] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", <a href="./rfc6833">RFC 6833</a>,
DOI 10.17487/RFC6833, January 2013,
<<a href="http://www.rfc-editor.org/info/rfc6833">http://www.rfc-editor.org/info/rfc6833</a>>.
[<a id="ref-RFC6834">RFC6834</a>] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", <a href="./rfc6834">RFC 6834</a>,
DOI 10.17487/RFC6834, January 2013,
<<a href="http://www.rfc-editor.org/info/rfc6834">http://www.rfc-editor.org/info/rfc6834</a>>.
[<a id="ref-RFC6836">RFC6836</a>] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", <a href="./rfc6836">RFC 6836</a>, DOI 10.17487/RFC6836,
January 2013, <<a href="http://www.rfc-editor.org/info/rfc6836">http://www.rfc-editor.org/info/rfc6836</a>>.
[<a id="ref-RFC7215">RFC7215</a>] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "Locator/Identifier Separation
Protocol (LISP) Network Element Deployment
Considerations", <a href="./rfc7215">RFC 7215</a>, DOI 10.17487/RFC7215, April
2014, <<a href="http://www.rfc-editor.org/info/rfc7215">http://www.rfc-editor.org/info/rfc7215</a>>.
<span class="grey">Saucez, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7834">RFC 7834</a> LISP Impact April 2016</span>
[<a id="ref-RFC7835">RFC7835</a>] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Threat Analysis", <a href="./rfc7835">RFC 7835</a>,
DOI 10.17487/RFC7835, April 2016,
<<a href="http://www.rfc-editor.org/info/rfc7835">http://www.rfc-editor.org/info/rfc7835</a>>.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Informative References</span>
[<a id="ref-CCR13">CCR13</a>] 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.
[<a id="ref-CDLC">CDLC</a>] 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.
[<a id="ref-CDM12">CDM12</a>] 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.
[<a id="ref-ConteXtream">ConteXtream</a>]
ConteXtream Software Company, , "SDN and NFV solutions for
carrier networks. (Further details on LISP only through
private inquiry.)", <<a href="http://www.contextream.com">http://www.contextream.com</a>>.
[<a id="ref-IB07">IB07</a>] 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.
[<a id="ref-IL10">IL10</a>] 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.
[<a id="ref-IOSNXOS">IOSNXOS</a>] Cisco Systems Inc., "Locator/ID Separation Protocol
(LISP)", 2015, <<a href="http://lisp4.cisco.com">http://lisp4.cisco.com</a>>.
[<a id="ref-KIF13">KIF13</a>] 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.
[<a id="ref-LISP-CRYPTO">LISP-CRYPTO</a>]
Farinacci, D. and B. Weis, "LISP Data-Plane
Confidentiality", Work in Progress,
<a href="./draft-ietf-lisp-crypto-03">draft-ietf-lisp-crypto-03</a>, September 2015.
<span class="grey">Saucez, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7834">RFC 7834</a> LISP Impact April 2016</span>
[<a id="ref-LISP-DDT">LISP-DDT</a>] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", Work in Progress,
<a href="./draft-ietf-lisp-ddt-03">draft-ietf-lisp-ddt-03</a>, April 2015.
[<a id="ref-LISP-ITR-GRACEFUL">LISP-ITR-GRACEFUL</a>]
Saucez, D., Bonaventure, O., Iannone, L., and C. Filsfils,
"LISP ITR Graceful Restart", Work in Progress,
<a href="./draft-saucez-lisp-itr-graceful-03">draft-saucez-lisp-itr-graceful-03</a>, December 2013.
[<a id="ref-LISP-LCAF">LISP-LCAF</a>]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", Work in Progress,
<a href="./draft-ietf-lisp-lcaf-12">draft-ietf-lisp-lcaf-12</a>, September 2015.
[<a id="ref-LISP-MN">LISP-MN</a>] Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
Mobile Node", Work in Progress, <a href="./draft-meyer-lisp-mn-14">draft-meyer-lisp-mn-14</a>,
July 2015.
[<a id="ref-LISP-MULTI-SIGNALING">LISP-MULTI-SIGNALING</a>]
Farinacci, D. and M. Napierala, "LISP Control-Plane
Multicast Signaling", Work in Progress, <a href="./draft-farinacci-lisp-mr-signaling-06">draft-farinacci-</a>
<a href="./draft-farinacci-lisp-mr-signaling-06">lisp-mr-signaling-06</a>, February 2015.
[<a id="ref-LISP-PRESERVE">LISP-PRESERVE</a>]
Bonaventure, O., Francois, P., and D. Saucez, "Preserving
the reachability of LISP ETRs in case of failures", Work
in Progress, <a href="./draft-bonaventure-lisp-preserve-00">draft-bonaventure-lisp-preserve-00</a>, July
2009.
[<a id="ref-LISP-RE">LISP-RE</a>] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J.,
Maino, F., and D. Farinacci, "LISP Replication
Engineering", Work in Progress, <a href="./draft-coras-lisp-re-08">draft-coras-lisp-re-08</a>,
November 2015.
[<a id="ref-LISP-SEC">LISP-SEC</a>] Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", Work in Progress,
<a href="./draft-ietf-lisp-sec-10">draft-ietf-lisp-sec-10</a>, October 2015.
[<a id="ref-LISP-SFM">LISP-SFM</a>] Moreno, V. and D. Farinacci, <a style="text-decoration: none" href='https://www.google.com/search?sitesearch=datatracker.ietf.org%2Fdoc%2Fhtml%2F&q=inurl:draft-+%22Signal-Free+LISP+Multicast%22'>"Signal-Free LISP Multicast"</a>,
Work in Progress, <a href="./draft-ietf-lisp-signal-free-multicast-01">draft-ietf-lisp-signal-free-</a>
<a href="./draft-ietf-lisp-signal-free-multicast-01">multicast-01</a>, April 2016.
[<a id="ref-LISP-TE">LISP-TE</a>] Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic
Engineering Use-Cases", Work in Progress,
<a href="./draft-farinacci-lisp-te-10">draft-farinacci-lisp-te-10</a>, September 2015.
<span class="grey">Saucez, et al. Informational [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7834">RFC 7834</a> LISP Impact April 2016</span>
[<a id="ref-LISPClick">LISPClick</a>]
Saucez, D. and V. Nguyen, "LISP-Click: A Click
implementation of the Locator/ID Separation Protocol", 1st
Symposium on Click Modular Router, November 2009,
<<a href="http://hdl.handle.net/2078.1/79067">http://hdl.handle.net/2078.1/79067</a>>.
[<a id="ref-LISPcp">LISPcp</a>] "LIP6-LISP open source project", 2014,
<<a href="https://github.com/lip6-lisp">https://github.com/lip6-lisp</a>>.
[<a id="ref-lispfirewall">lispfirewall</a>]
"LISP and Zone-Based Firewalls Integration and
Interoperability", 2014,
<<a href="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">http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/</a>
<a href="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">sec_data_zbf/configuration/xe-3s/sec-data-zbf-xe-book/</a>
<a href="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">sec-zbf-lisp-inner-pac-insp.html</a>>.
[<a id="ref-LISPfritz">LISPfritz</a>]
"Unsere FRITZ!Box-Produkte", 2014,
<<a href="http://avm.de/produkte/fritzbox/">http://avm.de/produkte/fritzbox/</a>>.
[<a id="ref-LISPmob">LISPmob</a>] "An open-source LISP implementation for Linux, Android and
OpenWRT", 2015, <<a href="http://lispmob.org">http://lispmob.org</a>>.
[<a id="ref-OpenLISP">OpenLISP</a>] "The OpenLISP Project", 2013, <<a href="http://www.openlisp.org">http://www.openlisp.org</a>>.
[<a id="ref-QIdLB07">QIdLB07</a>] 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.
[<a id="ref-RFC4984">RFC4984</a>] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
from the IAB Workshop on Routing and Addressing",
<a href="./rfc4984">RFC 4984</a>, DOI 10.17487/RFC4984, September 2007,
<<a href="http://www.rfc-editor.org/info/rfc4984">http://www.rfc-editor.org/info/rfc4984</a>>.
[<a id="ref-RFC7258">RFC7258</a>] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", <a href="https://www.rfc-editor.org/bcp/bcp188">BCP 188</a>, <a href="./rfc7258">RFC 7258</a>, DOI 10.17487/RFC7258, May
2014, <<a href="http://www.rfc-editor.org/info/rfc7258">http://www.rfc-editor.org/info/rfc7258</a>>.
[<a id="ref-S11">S11</a>] Saucez, D., "Mechanisms for Interdomain Traffic
Engineering with LISP", PhD Thesis, Universite catholique
de Louvain, September 2011,
<<a href="http://hdl.handle.net/2078.1/92231">http://hdl.handle.net/2078.1/92231</a>>.
[<a id="ref-SD12">SD12</a>] 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.
<span class="grey">Saucez, et al. Informational [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7834">RFC 7834</a> LISP Impact April 2016</span>
[<a id="ref-SDIB08">SDIB08</a>] 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.
[<a id="ref-SKI12">SKI12</a>] 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.
[<a id="ref-Was09">Was09</a>] Wasserman, M., "LISP Interoperability Testing", IETF
76, LISP WG Presentation, November 2009.
Acknowledgments
Thanks to Deborah Brungard, Ben Campbell, Spencer Dawkins, Stephen
Farrel, Wassim Haddad, Kathleen Moriarty, and Hilarie Orman for their
thorough reviews, comments, and suggestions.
The people that contributed to this document are Alia Atlas, Sharon
Barkai, Ron Bonica, Ross Callon, Vince Fuller, Joel Halpern, Terry
Manderson, and Gregg Schudel.
The work of Luigi Iannone has been partially supported by the
ANR 13 INFR 0009 LISP-Lab Project <<a href="http://www.lisp-lab.org">http://www.lisp-lab.org</a>>.
<span class="grey">Saucez, et al. Informational [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7834">RFC 7834</a> LISP Impact April 2016</span>
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
Saucez, et al. Informational [Page 18]
</pre>
|
