draft-ietf-lisp-interworking-05.txt   draft-ietf-lisp-interworking-06.txt 
Network Working Group D. Lewis Network Working Group D. Lewis
Internet-Draft D. Meyer Internet-Draft D. Meyer
Intended status: Experimental D. Farinacci Intended status: Experimental D. Farinacci
Expires: September 1, 2012 V. Fuller Expires: September 5, 2012 V. Fuller
Cisco Systems, Inc. Cisco Systems, Inc.
February 29, 2012 March 4, 2012
Interworking LISP with IPv4 and IPv6 Interworking LISP with IPv4 and IPv6
draft-ietf-lisp-interworking-05.txt draft-ietf-lisp-interworking-06.txt
Abstract Abstract
This document describes techniques for allowing sites running the This document describes techniques for allowing sites running the
Locator/ID Separation Protocol (LISP) to interoperate with Internet Locator/ID Separation Protocol (LISP) to interoperate with Internet
sites (which may be using either IPv4, IPv6, or both) but which are sites (which may be using either IPv4, IPv6, or both) but which are
not running LISP. A fundamental property of LISP speaking sites is not running LISP. A fundamental property of LISP speaking sites is
that they use Endpoint Identifiers (EIDs), rather than traditional IP that they use Endpoint Identifiers (EIDs), rather than traditional IP
addresses, in the source and destination fields of all traffic they addresses, in the source and destination fields of all traffic they
emit or receive. While EIDs are syntactically identical to IPv4 or emit or receive. While EIDs are syntactically identical to IPv4 or
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 1, 2012. This Internet-Draft will expire on September 5, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 18 skipping to change at page 3, line 18
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6
3. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 7 3. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 7
4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 8 4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 8
4.2. Requirement for sites to use BGP . . . . . . . . . . . . . 8 4.2. Requirement for sites to use BGP . . . . . . . . . . . . . 8
4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 8 4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 8
4.4. Use of Routable EIDs for sites transitioning to LISP . . . 8 4.4. Use of Routable EIDs for sites transitioning to LISP . . . 8
5. Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 10 5. Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 10
5.1. Proxy-ITR EID announcements . . . . . . . . . . . . . . . 10 5.1. Proxy-ITR EID announcements . . . . . . . . . . . . . . . 10
5.2. Packet Flow with Proxy-ITRs . . . . . . . . . . . . . . . 10 5.2. Packet Flow with Proxy-ITRs . . . . . . . . . . . . . . . 10
5.3. Scaling Proxy-ITRs . . . . . . . . . . . . . . . . . . . . 11 5.3. Scaling Proxy-ITRs . . . . . . . . . . . . . . . . . . . . 12
5.4. Impact of the Proxy-ITRs placement in the network . . . . 12 5.4. Impact of the Proxy-ITRs placement in the network . . . . 13
5.5. Benefit to Networks Deploying Proxy-ITRs . . . . . . . . . 12 5.5. Benefit to Networks Deploying Proxy-ITRs . . . . . . . . . 13
6. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 13 6. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 14
6.1. Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 13 6.1. Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 14
7. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 15 7.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 16
7.2. LISP Sites with Hosts using RFC 1918 Addresses Sending 7.2. LISP Sites with Hosts using RFC 1918 Addresses Sending
to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 16 to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 17
7.3. LISP Sites with Hosts using RFC 1918 Addresses 7.3. LISP Sites with Hosts using RFC 1918 Addresses
Sending Packets to Other LISP Sites . . . . . . . . . . . 16 Sending Packets to Other LISP Sites . . . . . . . . . . . 17
7.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 17 7.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 18
8. Discussion of Proxy-ITRs (Proxy-ITRs), LISP-NAT, and 8. Discussion of Proxy-ITRs (Proxy-ITRs), LISP-NAT, and
Proxy-ETRs (Proxy-ETRs) . . . . . . . . . . . . . . . . . . . 18 Proxy-ETRs (Proxy-ETRs) . . . . . . . . . . . . . . . . . . . 19
8.1. How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 18 8.1. How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.1. Normative References . . . . . . . . . . . . . . . . . . . 22 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23
12.2. Informative References . . . . . . . . . . . . . . . . . . 22 12.2. Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
This document describes interoperation mechanisms between LISP [LISP] This document describes interoperation mechanisms between LISP [LISP]
sites which use non-globally-routed EIDs, and non-LISP sites. A key sites which use non-globally-routed EIDs, and non-LISP sites. A key
behavior of the separation of Locators and Endpoint IDs is that EID behavior of the separation of Locators and Endpoint IDs is that EID
prefixes are normally not advertised into the Internet's Default Free prefixes are normally not advertised into the Internet's Default Free
Zone (DFZ). Specifically, only Routing Locators (RLOCs) are carried Zone (DFZ). (See section 4, for the exception case.) Specifically,
in the Internet's DFZ. Existing Internet sites (and their hosts) only Routing Locators (RLOCs) are carried in the Internet's DFZ.
which do not run in the LISP protocol must still be able to reach Existing Internet sites (and their hosts) which do not run in the
sites numbered from LISP EID space. This draft describes three LISP protocol must still be able to reach sites numbered from LISP
mechanisms that can be used to provide reachability between sites EID space. This document describes three mechanisms that can be used
that are LISP-capable and those that are not. to provide reachability between sites that are LISP-capable and those
that are not.
The first mechanism uses a new network element, the LISP Proxy The first mechanism uses a new network element, the LISP Proxy
Ingress Tunnel Router (Proxy-ITR) to act as a intermediate LISP Ingress Tunnel Router (Proxy-ITR) to act as a intermediate LISP
Ingress Tunnel Router (ITR) for non-LISP-speaking hosts. The second Ingress Tunnel Router (ITR) for non-LISP-speaking hosts. The second
mechanism adds a form of Network Address Translation (NAT) mechanism adds a form of Network Address Translation (NAT)
functionality to Tunnel Routers (xTRs), to substitute routable IP functionality to Tunnel Routers (xTRs), to substitute routable IP
addresses for non-routable EIDs. The final network element is the addresses for non-routable EIDs. The final network element is the
LISP Proxy Egress Tunnel Routers (Proxy-ETR), which act as an LISP Proxy Egress Tunnel Routers (Proxy-ETR), which act as an
intermediate Egress Tunnel Router (ETR) for LISP sites which need to intermediate Egress Tunnel Router (ETR) for LISP sites which need to
encapsulate LISP packets destined to non-LISP sites. encapsulate LISP packets destined to non-LISP sites.
skipping to change at page 7, line 46 skipping to change at page 7, line 46
There could be some situations where (unencapsulated) packets There could be some situations where (unencapsulated) packets
originated by a LISP site may not be forwarded to a non-LISP site. originated by a LISP site may not be forwarded to a non-LISP site.
These cases are reviewed in section 7, (Proxy Egress Tunnel Routers). These cases are reviewed in section 7, (Proxy Egress Tunnel Routers).
Case 4, typically the most challenging, occurs when a host at a non- Case 4, typically the most challenging, occurs when a host at a non-
LISP site wishes to send traffic to a host at a LISP site. If the LISP site wishes to send traffic to a host at a LISP site. If the
source host uses a (non-globally-routable) EID as the destination IP source host uses a (non-globally-routable) EID as the destination IP
address, the packet is forwarded inside the source site until it address, the packet is forwarded inside the source site until it
reaches a router which cannot forward it (due to lack of a default reaches a router which cannot forward it (due to lack of a default
route), at which point the traffic is dropped. For traffic not to be route), at which point the traffic is dropped. For traffic not to be
dropped, either some mechanism to make this destination EID routable dropped, some mechanism to make this destination EID routable must be
must be in place. Section 5 (Proxy-ITRs) and Section 6 (LISP-NAT) in place. Section 5 (Proxy-ITRs) and Section 6 (LISP-NAT) describe
describe two such mechanisms. Case 4 also applies to packets two such mechanisms. Case 4 also applies to packets returning to the
returning to the LISP site, in Case 3. LISP site, in Case 3.
4. Routable EIDs 4. Routable EIDs
An obvious way to achieve interworking between LISP and non-LISP An obvious way to achieve interworking between LISP and non-LISP
hosts is for a LISP site to simply announce EID prefixes into the hosts is for a LISP site to simply announce EID prefixes into the
DFZ, much like the current routing system, effectively treating them DFZ, much like the current routing system, effectively treating them
as "Provider Independent (PI)" prefixes. Having a site do this is as "Provider Independent (PI)" prefixes. Having a site do this is
undesirable as it defeats one of the primary goals of LISP - to undesirable as it defeats one of the primary goals of LISP - to
reduce global routing system state. reduce global routing system state.
skipping to change at page 8, line 26 skipping to change at page 8, line 26
If EID prefixes are announced into the DFZ, the impact is similar to If EID prefixes are announced into the DFZ, the impact is similar to
the case in which LISP has not been deployed, because these EID the case in which LISP has not been deployed, because these EID
prefixes will be no more aggregatable than existing PI addresses. prefixes will be no more aggregatable than existing PI addresses.
Such a mechanism is not viewed as a viable long term solution, but Such a mechanism is not viewed as a viable long term solution, but
may be a viable short term way for a site to transition a portion of may be a viable short term way for a site to transition a portion of
its address space to EID space without changing its existing routing its address space to EID space without changing its existing routing
policy. policy.
4.2. Requirement for sites to use BGP 4.2. Requirement for sites to use BGP
Routable EIDs might cause non-LISP sites today to use BGP to, among Routable EIDs might require non-LISP sites today to use BGP to, among
other things, originate their site's routes into the DFZ, and to other things, originate their site's routes into the DFZ, in order to
enable ingress traffic engineering. Relaxing this requirement while enable ingress traffic engineering. Relaxing this requirement, (thus
still letting sites control their ingress traffic engineering policy potentially reducing global DFZ routing state) while still letting
is another primary design goal of LISP. sites control their ingress traffic engineering policy is a design
goal of LISP.
4.3. Limiting the Impact of Routable EIDs 4.3. Limiting the Impact of Routable EIDs
Two schemes are proposed to limit the impact of having EIDs announced Two schemes are proposed to limit the impact of having EIDs announced
in the current global Internet routing table: in the current global Internet routing table:
1. Section 5 discusses the LISP Proxy Ingress Tunnel Router, an 1. Section 5 discusses the LISP Proxy Ingress Tunnel Router, an
approach that provides ITR functionality to bridge LISP-capable approach that provides ITR functionality to bridge LISP-capable
and non-LISP-capable sites. and non-LISP-capable sites.
skipping to change at page 10, line 42 skipping to change at page 10, line 42
forwarding load to be spread among many Proxy-ITRs. forwarding load to be spread among many Proxy-ITRs.
5.2. Packet Flow with Proxy-ITRs 5.2. Packet Flow with Proxy-ITRs
What follows is an example of the path a packet would take when using What follows is an example of the path a packet would take when using
a Proxy-ITR. In this example, the LISP-NR site is given the EID a Proxy-ITR. In this example, the LISP-NR site is given the EID
prefix 192.0.2.0/24. For the purposes of this example, neither this prefix 192.0.2.0/24. For the purposes of this example, neither this
prefix nor any covering aggregate are present in the global routing prefix nor any covering aggregate are present in the global routing
system. In other words, without the Proxy-ITR announcing system. In other words, without the Proxy-ITR announcing
192.0.2.0/24, if a packet with this destination were to reach a 192.0.2.0/24, if a packet with this destination were to reach a
router in the "Default Free Zone", it would be dropped. router in the "Default Free Zone", it would be dropped. The
following diagram describes a high level view of the topology:
Internet DFZ
.--------------------------------.
/ \
| Traffic Encap'd to Site's |
| +-----+ RLOC(s) | LISP Site:
| |P-ITR|=========> |
| +-----+ +--+ +-----+ |
| | |PE+------+CE 1 |-|
| | Originated Rout +--+ +-----+ | +----+
| V 192.0.2.0/24 | |-|Host|
| +--| +-----+ | +----+
| |PE+------+CE 2 |-| 192.0.2.1
| +---+ +--+ +-----+ |
\ |PE | /
'---------------+-+-+------------' Site EID Prefix:
| 192.0.2.0/24
| ^
| |
+--+--+ | Traffic
Non LISP Site: | CE | | to
+--+--+ | 192.168.2.1
| |
-----------
|
+----+
|Host|
+----+
Figure 1: Example of Proxy-ITR Packet Flow
A full protocol exchange example follows: A full protocol exchange example follows:
1. The source host makes a DNS lookup EID for destination, and gets 1. The source host makes a DNS lookup EID for destination, and gets
192.0.2.1 in return. 192.0.2.1 in return.
2. The source host has a default route to Customer Edge (CE) router 2. The source host has a default route to Customer Edge (CE) router
and forwards the packet to the CE. and forwards the packet to the CE.
3. The CE has a default route to its Provider Edge (PE) router, and 3. The CE has a default route to its Provider Edge (PE) router, and
skipping to change at page 16, line 11 skipping to change at page 17, line 11
of this PA space (192.0.2.2 to 192.0.2.254) is used as a translation of this PA space (192.0.2.2 to 192.0.2.254) is used as a translation
pool for this site's hosts who need to send packets to non-LISP pool for this site's hosts who need to send packets to non-LISP
hosts. hosts.
The translation table might look like the following: The translation table might look like the following:
Site NR-EID Site R-EID Site's RLOC Translation Pool Site NR-EID Site R-EID Site's RLOC Translation Pool
============================================================== ==============================================================
203.0.113.0/24 192.0.2.0/24 192.0.2.1 192.0.2.2-254 203.0.113.0/24 192.0.2.0/24 192.0.2.1 192.0.2.2-254
Figure 1: Example Translation Table Figure 2: Example Translation Table
The host 203.0.113.2 sends a packet (which, for the purposes of this The host 203.0.113.2 sends a packet (which, for the purposes of this
example is destined for a non-LISP site) to its default route (the example is destined for a non-LISP site) to its default route (the
ITR). The ITR receives the packet, and determines that the ITR). The ITR receives the packet, and determines that the
destination is not a LISP site. How the ITR makes this determination destination is not a LISP site. How the ITR makes this determination
is up to the ITRs implementation of the EID-to-RLOC mapping system is up to the ITRs implementation of the EID-to-RLOC mapping system
used (see, for example [LISP-ALT]). used (see, for example [LISP-ALT]).
The ITR then rewrites the source address of the packet from The ITR then rewrites the source address of the packet from
203.0.113.2 to 192.0.2.2, which is the first available address in the 203.0.113.2 to 192.0.2.2, which is the first available address in the
skipping to change at page 16, line 40 skipping to change at page 17, line 40
7.2. LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP 7.2. LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP
Sites Sites
In the case where hosts using RFC 1918 addresses desire to send In the case where hosts using RFC 1918 addresses desire to send
packets to non-LISP hosts, the LISP-NAT implementation acts much like packets to non-LISP hosts, the LISP-NAT implementation acts much like
an existing IPv4 NAT device that is doing address only (not port an existing IPv4 NAT device that is doing address only (not port
translation. The ITR providing the NAT service must use LISP-R EIDs translation. The ITR providing the NAT service must use LISP-R EIDs
for its global address pool as well as providing all the standard NAT for its global address pool as well as providing all the standard NAT
functions required today. functions required today.
Note that the RFC 1918 addresses above are private addresses, not
EIDs, and these RFC 1918 addresses are not found in the LISP mapping
system.
The source of the packet must be translated to a LISP-R EID in a The source of the packet must be translated to a LISP-R EID in a
manner similar to Section 7, and this packet must be forwarded to the manner similar to Section 7, and this packet must be forwarded to the
ITR's next hop for the destination, without LISP encapsulation. ITR's next hop for the destination, without LISP encapsulation.
7.3. LISP Sites with Hosts using RFC 1918 Addresses Sending Packets 7.3. LISP Sites with Hosts using RFC 1918 Addresses Sending Packets
to Other LISP Sites to Other LISP Sites
LISP-NAT allows a host with an RFC 1918 address to send packets to LISP-NAT allows a host with an RFC 1918 address to send packets to
LISP hosts by translating the RFC 1918 address to a LISP EID. After LISP hosts by translating the RFC 1918 address to a LISP EID. After
translation, the communication between source and destination ITR and translation, the communication between source and destination ITR and
ETRs continues as described in [LISP]. ETRs continues as described in [LISP].
While the communication of LISP EIDs to LISP EIDs is, strictly
speaking, outside the scope of Interworking, it is included here in
order to complete the conceptual framework of LISP-NAT.
An example of this translation and encapsulation follows. For this An example of this translation and encapsulation follows. For this
example, a host has been assigned a RFC 1918 address of 192.168.1.2. example, a host has been assigned a RFC 1918 address of 192.168.1.2.
In order to utilize LISP-NAT, the site also has been provided the In order to utilize LISP-NAT, the site also has been provided the
LISP-R EID prefix of 192.0.2.0/24, and uses the first address LISP-R EID prefix of 192.0.2.0/24, and uses the first address
(192.0.2.1) as the site's RLOC. The rest of this PA space (192.0.2.2 (192.0.2.1) as the site's RLOC. The rest of this PA space (192.0.2.2
to 192.0.2.254) is used as a translation pool for this site's hosts to 192.0.2.254) is used as a translation pool for this site's hosts
who need to send packets to both non-LISP and LISP hosts. who need to send packets to both non-LISP and LISP hosts.
The host 192.168.1.2 sends a packet destined for a non-LISP site to The host 192.168.1.2 sends a packet destined for a non-LISP site to
its default route (the ITR). The ITR receives the packet and its default route (the ITR). The ITR receives the packet and
skipping to change at page 18, line 8 skipping to change at page 19, line 8
general, but the specific issue described above is unique to general, but the specific issue described above is unique to
location/identity separation schemes. Some of these have suggested location/identity separation schemes. Some of these have suggested
running a separate DNS instance for new types of EIDs. This solves running a separate DNS instance for new types of EIDs. This solves
the problem but introduces complexity for the site. Alternatively, the problem but introduces complexity for the site. Alternatively,
using Proxy-ITRs can mitigate this problem, because the LISP-NR EID using Proxy-ITRs can mitigate this problem, because the LISP-NR EID
can be reached in all cases. can be reached in all cases.
8. Discussion of Proxy-ITRs (Proxy-ITRs), LISP-NAT, and Proxy-ETRs 8. Discussion of Proxy-ITRs (Proxy-ITRs), LISP-NAT, and Proxy-ETRs
(Proxy-ETRs) (Proxy-ETRs)
In summary, there are three mechanisms for interworking LISP with In summary, there are three suggested mechanisms for interworking
non-LISP Sites (for both IPv4 and IPv6). In the LISP-NAT option the LISP with non-LISP Sites (for both IPv4 and IPv6). In the LISP-NAT
LISP site can manage and control the interworking on its own. In the option the LISP site can manage and control the interworking on its
Proxy-ITR case, the site is not required to manage the advertisement own. In the Proxy-ITR case, the site is not required to manage the
of it's EID prefix into the DFZ, with the cost of potentially adding advertisement of it's EID prefix into the DFZ, with the cost of
stretch to the connections of non-LISP sites sending packets to the potentially adding stretch to the connections of non-LISP sites
LISP site. The third option is Proxy-ETRs, which are optionally used sending packets to the LISP site. The third option is Proxy-ETRs,
by sites relying on Proxy-ITRs to mitigate two caveats for LISP sites which are optionally used by sites relying on Proxy-ITRs to mitigate
sending packets to non-LISP sites. This means Proxy-ETRs are not two caveats for LISP sites sending packets to non-LISP sites. This
usually expected to be deployed by themselves, rather they will be means Proxy-ETRs are not usually expected to be deployed by
used to assist LISP-NR sites which are already using Proxy-ITRs. themselves, rather they will be used to assist LISP-NR sites which
are already using Proxy-ITRs.
8.1. How Proxy-ITRs and Proxy-ETRs Interact 8.1. How Proxy-ITRs and Proxy-ETRs Interact
There is a subtle difference between Symmetrical (LISP-NAT) vs There is a subtle difference between Symmetrical (LISP-NAT) vs
Asymmetrical (Proxy-ITR and Proxy-ETR) Interworking techniques. Asymmetrical (Proxy-ITR and Proxy-ETR) Interworking techniques.
Operationally, Proxy-ITRs (Proxy-ITRs) and Proxy-ETRs (Proxy-ETRs) Operationally, Proxy-ITRs (Proxy-ITRs) and Proxy-ETRs (Proxy-ETRs)
can (and likely should) be decoupled since Proxy-ITRs are best can (and likely should) be decoupled since Proxy-ITRs are best
deployed closest to non-LISP sites, and Proxy-ETRs are best located deployed closest to non-LISP sites, and Proxy-ETRs are best located
close to the LISP sites they are decapsulating for. This asymmetric close to the LISP sites they are decapsulating for. This asymmetric
placement of the two network elements minimizes the stretch imposed placement of the two network elements minimizes the stretch imposed
 End of changes. 16 change blocks. 
51 lines changed or deleted 94 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/