draft-ietf-lisp-lig-05.txt   draft-ietf-lisp-lig-06.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft D. Meyer Internet-Draft D. Meyer
Intended status: Experimental cisco Systems Intended status: Experimental cisco Systems
Expires: March 9, 2012 September 6, 2011 Expires: March 12, 2012 September 9, 2011
LISP Internet Groper (LIG) LISP Internet Groper (LIG)
draft-ietf-lisp-lig-05 draft-ietf-lisp-lig-06
Abstract Abstract
A simple tool called the LISP Internet Groper or 'lig' can be used to A simple tool called the LISP Internet Groper or 'lig' can be used to
query the LISP mapping database. This draft describes how it works. query the LISP mapping database. This draft describes how it works.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
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 March 9, 2012. This Internet-Draft will expire on March 12, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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 21 skipping to change at page 3, line 21
infrastructure. To achieve this separation, the Locator/ID infrastructure. To achieve this separation, the Locator/ID
Separation Protocol (LISP) defines protocol mechanisms for mapping Separation Protocol (LISP) defines protocol mechanisms for mapping
from EIDs to RLOCs. In addition, LISP assumes the existence of a from EIDs to RLOCs. In addition, LISP assumes the existence of a
database to store and propagate those mappings globally. Several database to store and propagate those mappings globally. Several
such databases have been proposed, among them: LISP-CONS [CONS], such databases have been proposed, among them: LISP-CONS [CONS],
LISP-NERD [NERD], and LISP+ALT [ALT], with LISP+ALT being the system LISP-NERD [NERD], and LISP+ALT [ALT], with LISP+ALT being the system
that is currently being implemented and deployed on the pilot LISP that is currently being implemented and deployed on the pilot LISP
network. network.
In conjunction with the various mapping systems, there exists a In conjunction with the various mapping systems, there exists a
network based API called LISP Map-Server [LISP-MS]. Using Map network based API called LISP Map-Server [LISP-MS]. Using Map-
Resolvers and Map Servers allows LISP sites to query and register Resolvers and Map-Servers allows LISP sites to query and register
into the database in a uniform way independent of the mapping system into the database in a uniform way independent of the mapping system
used. Sending Map-Requests to Map Resolvers provides a secure used. Sending Map-Requests to Map-Resolvers provides a secure
mechanism to obtain a Map-Reply containing the authoritative EID-to- mechanism to obtain a Map-Reply containing the authoritative EID-to-
RLOC mapping for a destination LISP site. RLOC mapping for a destination LISP site.
The 'lig' is a manual management tool to query the mapping database. The 'lig' is a manual management tool to query the mapping database.
It can be run by all devices which implement LISP, including ITRs, It can be run by all devices which implement LISP, including ITRs,
ETRs, PTR, Map-Resolvers, Map-Servers, and LISP-ALT routers, as well ETRs, PITRs, PETRs, Map-Resolvers, Map-Servers, and LISP-ALT routers,
as by a host system at either a LISP-capable or non-LISP-capable as well as by a host system at either a LISP-capable or non-LISP-
site. capable site.
The mapping database system is typically a public database used for
wide-range connectivity across Internet sites. The information in
the public database is purposely not kept private so it can be
generally accessible for public use.
2. Definition of Terms 2. Definition of Terms
Map-Server: a network infrastructure component which learns EID-to- Map-Server: a network infrastructure component which learns EID-to-
RLOC mapping entries from an authoritative source (typically, an RLOC mapping entries from an authoritative source (typically, an
ETR, though static configuration or another out-of-band mechanism ETR, though static configuration or another out-of-band mechanism
may be used). A Map-Server advertises these mappings in the may be used). A Map-Server advertises these mappings in the
distributed mapping database. distributed mapping database.
Map-Resolver: a network infrastructure component which accepts LISP Map-Resolver: a network infrastructure component which accepts LISP
skipping to change at page 4, line 26 skipping to change at page 4, line 26
the EID namespace; if it is not, a Negative Map-Reply is the EID namespace; if it is not, a Negative Map-Reply is
immediately returned. Otherwise, the Map-Resolver finds the immediately returned. Otherwise, the Map-Resolver finds the
appropriate EID-to-RLOC mapping by consulting the distributed appropriate EID-to-RLOC mapping by consulting the distributed
mapping database system. mapping database system.
Routing Locator (RLOC): the IPv4 or IPv6 address of an egress Routing Locator (RLOC): the IPv4 or IPv6 address of an egress
tunnel router (ETR). It is the output of a EID-to-RLOC mapping tunnel router (ETR). It is the output of a EID-to-RLOC mapping
lookup. An EID maps to one or more RLOCs. Typically, RLOCs are lookup. An EID maps to one or more RLOCs. Typically, RLOCs are
numbered from topologically-aggregatable blocks that are assigned numbered from topologically-aggregatable blocks that are assigned
to a site at each point to which it attaches to the global to a site at each point to which it attaches to the global
Internet; where the topology is defined by the connectivity of Internet. Thus, the topology is defined by the connectivity of
provider networks, RLOCs can be thought of as PA addresses. provider networks and RLOCs can be thought of as PA addresses.
Multiple RLOCs can be assigned to the same ETR device or to Multiple RLOCs can be assigned to the same ETR device or to
multiple ETR devices at a site. multiple ETR devices at a site.
Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value
used in the source and destination address fields of the first used in the source and destination address fields of the first
(most inner) LISP header of a packet. The host obtains a (most inner) LISP header of a packet. The host obtains a
destination EID the same way it obtains a destination address destination EID the same way it obtains a destination address
today, for example through a DNS lookup or SIP exchange. The today, for example through a DNS lookup. The source EID is
source EID is obtained via existing mechanisms used to set a obtained via existing mechanisms used to set a host's "local" IP
host's "local" IP address. An EID is allocated to a host from an address. An EID is allocated to a host from an EID-prefix block
EID-prefix block associated with the site where the host is associated with the site where the host is located. An EID can be
located. An EID can be used by a host to refer to other hosts. used by a host to refer to other hosts. EIDs must not be used as
EIDs must not be used as LISP RLOCs. Note that EID blocks may be LISP RLOCs. Note that EID blocks may be assigned in a
assigned in a hierarchical manner, independent of the network hierarchical manner, independent of the network topology, to
topology, to facilitate scaling of the mapping database. In facilitate scaling of the mapping database. In addition, an EID
addition, an EID block assigned to a site may have site-local block assigned to a site may have site-local structure
structure (subnetting) for routing within the site; this structure (subnetting) for routing within the site; this structure is not
is not visible to the global routing system. visible to the global routing system.
EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that
stores, tracks, and is responsible for timing-out and otherwise stores, tracks, and is responsible for timing-out and otherwise
validating EID-to-RLOC mappings. This cache is distinct from the validating EID-to-RLOC mappings. This cache is distinct from the
full "database" of EID-to-RLOC mappings, it is dynamic, local to full "database" of EID-to-RLOC mappings, it is dynamic, local to
the ITR(s), and relatively small while the database is the ITR(s), and relatively small while the database is
distributed, relatively static, and much more global in scope. distributed, relatively static, and much more global in scope.
EID-to-RLOC Database: a global distributed database that contains EID-to-RLOC Database: a global distributed database that contains
all known EID-prefix to RLOC mappings. Each potential ETR all known EID-prefix to RLOC mappings. Each potential ETR
typically contains a small piece of the database: the EID-to-RLOC typically contains a small piece of the database: the EID-to-RLOC
mappings for the EID prefixes "behind" the router. These map to mappings for the EID prefixes "behind" the router. These map to
one of the router's own, globally-visible, IP addresses. one of the router's own, globally-visible, IP addresses.
Encapsulated Map-Request (EMR): an EMR is a Map-Request message Encapsulated Map-Request (EMR): an EMR is a Map-Request message
which is encapsulated with another LISP header using UDP which is encapsulated with another LISP header using UDP
destination port number 4341. It is used so an ITR, PTR, or a destination port number 4341. It is used so an ITR, PITR, or a
system initiating a 'lig' command can get the Map-Request to a system initiating a 'lig' command can get the Map-Request to a
Map-Resolver by using locater addresses. When the Map-Request is Map-Resolver by using locater addresses. When the Map-Request is
decapsulated by the Map-Resolver it will be forwarded on the ALT decapsulated by the Map-Resolver it will be forwarded on the ALT
network to the Map-Server that has injected the EID-prefix for a network to the Map-Server that has injected the EID-prefix for a
registered site. The Map-Server will then encapsulate the Map- registered site. The Map-Server will then encapsulate the Map-
Request in a LISP packet and send it to an an ETR at the site. Request in a LISP packet and send it to an an ETR at the site.
The ETR will then return an authoritative reply to the system that The ETR will then return an authoritative reply to the system that
initiated the request. See [LISP] for packet format details. initiated the request. See [LISP] for packet format details.
Ingress Tunnel Router (ITR): An ITR is a router which accepts an IP Ingress Tunnel Router (ITR): An ITR is a router which accepts an IP
skipping to change at page 5, line 47 skipping to change at page 5, line 47
Egress Tunnel Router (ETR): An ETR is a router that accepts an IP Egress Tunnel Router (ETR): An ETR is a router that accepts an IP
packet where the destination address in the "outer" IP header is packet where the destination address in the "outer" IP header is
one of its own RLOCs. The router strips the "outer" header and one of its own RLOCs. The router strips the "outer" header and
forwards the packet based on the next IP header found. In forwards the packet based on the next IP header found. In
general, an ETR receives LISP-encapsulated IP packets from the general, an ETR receives LISP-encapsulated IP packets from the
Internet on one side and sends decapsulated IP packets to site Internet on one side and sends decapsulated IP packets to site
end-systems on the other side. ETR functionality does not have to end-systems on the other side. ETR functionality does not have to
be limited to a router device. A server host can be the endpoint be limited to a router device. A server host can be the endpoint
of a LISP tunnel as well. of a LISP tunnel as well.
Proxy ITR (PITR): A PITR is also known as a PTR is defined and
described in [INTERWORK], a PITR acts like an ITR but does so on
behalf of non-LISP sites which send packets to destinations at
LISP sites.
Proxy ETR (PETR): A PETR is defined and described in [INTERWORK], a
PETR acts like an ETR but does so on behalf of LISP sites which
send packets to destinations at non-LISP sites.
xTR: A xTR is a reference to an ITR or ETR when direction of data xTR: A xTR is a reference to an ITR or ETR when direction of data
flow is not part of the context description. xTR refers to the flow is not part of the context description. xTR refers to the
router that is the tunnel endpoint. Used synonymously with the router that is the tunnel endpoint. Used synonymously with the
term "Tunnel Router". For example, "An xTR can be located at the term "Tunnel Router". For example, "An xTR can be located at the
Customer Edge (CE) router", meaning both ITR and ETR functionality Customer Edge (CE) router", meaning both ITR and ETR functionality
is at the CE router. is at the CE router.
Provider Assigned (PA) Addresses: PA addresses are an a address Provider Assigned (PA) Addresses: PA addresses are an address block
block assigned to a site by each service provider to which a site assigned to a site by each service provider to which a site
connects. Typically, each block is sub-block of a service connects. Typically, each block is sub-block of a service
provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and
is aggregated into the larger block before being advertised into is aggregated into the larger block before being advertised into
the global Internet. Traditionally, IP multihoming has been the global Internet. Traditionally, IP multihoming has been
implemented by each multi-homed site acquiring its own, globally- implemented by each multi-homed site acquiring its own, globally-
visible prefix. LISP uses only topologically-assigned and visible prefix. LISP uses only topologically-assigned and
aggregatable address blocks for RLOCs, eliminating this aggregatable address blocks for RLOCs, eliminating this
demonstrably non-scalable practice. demonstrably non-scalable practice.
3. Basic Overview 3. Basic Overview
skipping to change at page 7, line 36 skipping to change at page 7, line 36
<destination>: is either a Fully Qualified Domain Name or a <destination>: is either a Fully Qualified Domain Name or a
destination EID for a remote LISP site. destination EID for a remote LISP site.
source <source>: is an optional source EID to be inserted in the source <source>: is an optional source EID to be inserted in the
"Source EID" field of the Map-Request. "Source EID" field of the Map-Request.
to <map-resolver>: is an optional Fully Qualified Domain Name or to <map-resolver>: is an optional Fully Qualified Domain Name or
RLOC address for a Map-Resolver. RLOC address for a Map-Resolver.
The lig utility has two usage cases. The first being a way to query The lig utility has two use cases. The first being a way to query
the mapping database for a particular EID. And the other to verify the mapping database for a particular EID. And the other to verify
if a site has registered successfully with a Map-Server. if a site has registered successfully with a Map-Server.
The first usage has already been described. Verifying registration The first usage has already been described. Verifying registration
is called "ligging yourself". What occurs is in the lig initiator, a is called "ligging yourself". What occurs is in the lig initiator, a
Map-Request is sent for one of the EIDs for the lig initiator's site. Map-Request is sent for one of the EIDs for the lig initiator's site.
The Map-Request is then returned to one of the ETRs for the lig The Map-Request is then returned to one of the ETRs for the lig
initiating site. In response to the Map-Request, a Map-Reply is sent initiating site. In response to the Map-Request, a Map-Reply is sent
back to the locator address of the lig initiator (note the Map-Reply back to the locator address of the lig initiator (note the Map-Reply
could be sent by the lig initiator). That Map-Reply is processed and could be sent by the lig initiator). That Map-Reply is processed and
the mapping data for lig initiating site is displayed for the user. the mapping data for the lig initiating site is displayed for the
Refer to the syntax in section Section 4.1 for an implementation of user. Refer to the syntax in section Section 4.1 for an
"ligging yourself". However, for host-based implementations within a implementation of "ligging yourself". However, for host-based
LISP site, "lig self" is less useful since the host may not have an implementations within a LISP site, "lig self" is less useful since
RLOC to receive a Map-Reply with. But, lig can be used in a non-LISP the host may not have an RLOC to receive a Map-Reply with. But, lig
site as well as from infrastructure hosts to get mapping information. can be used in a non-LISP site as well as from infrastructure hosts
to get mapping information.
4. Implementation Details 4. Implementation Details
4.1. LISP Router Implementation 4.1. LISP Router Implementation
The cisco LISP prototype implementation has support for lig for IPv4 The cisco LISP prototype implementation has support for lig for IPv4
and IPv6. The command line description is: and IPv6. The command line description is:
lig <dest-eid> [source <source-eid>] [to <mr>] [count <1-5>] lig <dest-eid> [source <source-eid>] [to <mr>] [count <1-5>]
skipping to change at page 9, line 31 skipping to change at page 9, line 31
DNS name, or an IPv4 or IPv6 EID address. The <source-eid> can be DNS name, or an IPv4 or IPv6 EID address. The <source-eid> can be
one of the EID addresses assigned to the site in the default VRF. one of the EID addresses assigned to the site in the default VRF.
When <mr> is specified, then the Map-Request is sent to the address. When <mr> is specified, then the Map-Request is sent to the address.
Otherwise, the Map-Request is sent to a configured Map-Resolver. Otherwise, the Map-Request is sent to a configured Map-Resolver.
When a Map-Resolver is not configured then the Map-Request is sent on When a Map-Resolver is not configured then the Map-Request is sent on
the ALT network if the local router is attached to the ALT. When the ALT network if the local router is attached to the ALT. When
"count <1-5>" is specified, 1, 2, 3, 4, or 5 Map-Requests are sent. "count <1-5>" is specified, 1, 2, 3, 4, or 5 Map-Requests are sent.
Some sample output: Some sample output:
titanium-dino# lig titanium-dmm.lisp4.net router# lig abc.example.com
Send map-request to 10.0.0.1 for 192.168.1.1 ... Send map-request to 10.0.0.1 for 192.168.1.1 ...
Received map-reply from 10.0.0.2 with rtt 0.081468 secs Received map-reply from 10.0.0.2 with rtt 0.081468 secs
Map-cache entry for titanium-dmm.lisp4.net EID 192.168.1.1: Map-cache entry for abc.example.com EID 192.168.1.1:
192.168.1.0/24, uptime: 13:59:59, expires: 23:59:58, 192.168.1.0/24, uptime: 13:59:59, expires: 23:59:58,
via map-reply, auth via map-reply, auth
Locator Uptime State Priority/Weight Packets In/Out Locator Uptime State Priority/Weight Packets In/Out
10.0.0.2 13:59:59 up 1/100 0/14 10.0.0.2 13:59:59 up 1/100 0/14
Using lig to "lig yourself" is accomplished with the following Using lig to "lig yourself" is accomplished with the following
syntax: syntax:
lig {self | self6} [source <source-eid>] [to <mr>] [count <1-5>] lig {self | self6} [source <source-eid>] [to <mr>] [count <1-5>]
skipping to change at page 10, line 14 skipping to change at page 10, line 14
is 192.168.1.0/24, the destination-EID for the Map-Request is is 192.168.1.0/24, the destination-EID for the Map-Request is
192.168.1.0. The source-EID address for the Map-Request will also be 192.168.1.0. The source-EID address for the Map-Request will also be
192.168.1.0 (in this example) and the Map-Request is sent to the 192.168.1.0 (in this example) and the Map-Request is sent to the
configured Map-Resolver. If the Map-Resolver and Map-Server are the configured Map-Resolver. If the Map-Resolver and Map-Server are the
same LISP system, then the "lig self" is testing if the Map-Resolver same LISP system, then the "lig self" is testing if the Map-Resolver
can "turn back a Map-Request to the site". If another Map-Resolver can "turn back a Map-Request to the site". If another Map-Resolver
is used, it can test that the site's EID-prefix has been injected is used, it can test that the site's EID-prefix has been injected
into the ALT infrastructure in which case the lig Map-Request is into the ALT infrastructure in which case the lig Map-Request is
processed by the Map-Resolver, propagated through each ALT router hop processed by the Map-Resolver, propagated through each ALT router hop
to the site's registered Map-Server. Then the Map-Server returns the to the site's registered Map-Server. Then the Map-Server returns the
Map-Request to originating site. In which case, an xTR at the Map-Request to the originating site. In which case, an xTR at the
originating site sends a Map-Reply to the source of the Map-Request originating site sends a Map-Reply to the source of the Map-Request
(could be itself or another xTR for the site). All other command (could be itself or another xTR for the site). All other command
parameters are described above. Using "lig self6" tests for parameters are described above. Using "lig self6" tests for
registering of IPv6 EID- prefixes. registering of IPv6 EID- prefixes.
Some sample output for ligging yourself: Some sample output for ligging yourself:
rutile# lig self router# lig self
Send loopback map-request to 10.0.0.1 for 192.168.2.0 ... Send loopback map-request to 10.0.0.1 for 192.168.2.0 ...
Received map-reply from 10.0.0.3 with rtt 0.001592 secs Received map-reply from 10.0.0.3 with rtt 0.001592 secs
Map-cache entry for EID 192.168.2.0: Map-cache entry for EID 192.168.2.0:
192.168.2.0/24, uptime: 00:00:02, expires: 23:59:57 192.168.2.0/24, uptime: 00:00:02, expires: 23:59:57
via map-reply, self via map-reply, self
Locator Uptime State Priority/Weight Packets In/Out Locator Uptime State Priority/Weight Packets In/Out
10.0.0.3 00:00:02 up 1/100 0/0 10.0.0.3 00:00:02 up 1/100 0/0
titanium-simlo# lig self6 router# lig self6
Send loopback map-request to 10.0.0.1 for 2001:db8:1:: ... Send loopback map-request to 10.0.0.1 for 2001:db8:1:: ...
Received map-reply from 10::1 with rtt 0.044372 secs Received map-reply from 10::1 with rtt 0.044372 secs
Map-cache entry for EID 192:168:1::: Map-cache entry for EID 192:168:1:::
2001:db8:1::/48, uptime: 00:00:01, expires: 23:59:58 2001:db8:1::/48, uptime: 00:00:01, expires: 23:59:58
via map-reply, self via map-reply, self
Locator Uptime State Priority/Weight Packets In/Out Locator Uptime State Priority/Weight Packets In/Out
10.0.0.3 00:00:01 up 1/100 0/0 10.0.0.3 00:00:01 up 1/100 0/0
2001:db8:ffff::1 00:00:01 up 2/0 0/0 2001:db8:ffff::1 00:00:01 up 2/0 0/0
skipping to change at page 11, line 25 skipping to change at page 11, line 25
-c <count>: the number of Map-Requests to send before the first Map- -c <count>: the number of Map-Requests to send before the first Map-
Reply is returned. The default value is 3. The range is from 1 Reply is returned. The default value is 3. The range is from 1
to 5. to 5.
-t <timeout>: the amount of time, in seconds, before another Map- -t <timeout>: the amount of time, in seconds, before another Map-
Request is sent when no Map-Reply is returned. The default value Request is sent when no Map-Reply is returned. The default value
is 2 seconds. The range is from 1 to 5. is 2 seconds. The range is from 1 to 5.
Some sample output: Some sample output:
% lig titanium-test.lisp4.net -m 10.0.0.1 % lig xyz.example.com -m 10.0.0.1
Send map-request to 10.0.0.1 for 192.168.1.1 ... Send map-request to 10.0.0.1 for 192.168.1.1 ...
Received map-reply from 10.0.0.2 with rtt 0.04000 sec Received map-reply from 10.0.0.2 with rtt 0.04000 sec
Mapping entry for EID 192.168.1.1: Mapping entry for EID 192.168.1.1:
192.168.1.0/24, record ttl: 60 192.168.1.0/24, record ttl: 60
Locator State Priority/Weight Locator State Priority/Weight
10.0.0.1 up 1/25 10.0.0.1 up 1/25
10.0.0.2 up 1/25 10.0.0.2 up 1/25
10.0.0.3 up 1/25 10.0.0.3 up 1/25
10.0.0.4 up 2/25 10.0.0.4 up 2/25
skipping to change at page 12, line 26 skipping to change at page 12, line 26
testing the ALT. This occurs because the Map-Server is the source of testing the ALT. This occurs because the Map-Server is the source of
the advertisement for the site's EID-prefix. So if the map-reply is the advertisement for the site's EID-prefix. So if the map-reply is
returned to the lig requesting site, you cannot be sure that other returned to the lig requesting site, you cannot be sure that other
sites can reach the same destination-EID. sites can reach the same destination-EID.
If a Map-Resolver is used that is not a Map-Server for the EID-prefix If a Map-Resolver is used that is not a Map-Server for the EID-prefix
being sought, then the ALT infrastructure can be tested. This test being sought, then the ALT infrastructure can be tested. This test
case is testing the functionality of the Map-Resolver, traversal of case is testing the functionality of the Map-Resolver, traversal of
the ALT (testing BGP-over-GRE), and the Map-Server. the ALT (testing BGP-over-GRE), and the Map-Server.
It is recommended that users issue 2 lig requests, each which send It is recommended that users issue 2 lig requests, each of which send
Map-Requests to different Map-Resolvers. Map-Requests to different Map-Resolvers.
The network can have a LISP-ALT router deployed as a "ALT looking- The network can have a LISP-ALT router deployed as a "ALT looking-
glass" node. This type of router has BGP peering sessions with other glass" node. This type of router has BGP peering sessions with other
ALT routers where it does not inject any EID-prefixes into the ALT ALT routers where it does not inject any EID-prefixes into the ALT
but just learns ones advertised by other ALT routers and Map-Servers. but just learns ones advertised by other ALT routers and Map-Servers.
This router is configured as a Map-Resolver. Lig users can point to This router is configured as a Map-Resolver. Lig users can point to
the ALT looking-glass router for Map-Resolver services via the "to the ALT looking-glass router for Map-Resolver services via the "to
<map-resolver>" parameter on the lig command. The ALT looking-glass <map-resolver>" parameter on the lig command. The ALT looking-glass
node can be used to lig other sites as well as your own site. When node can be used to lig other sites as well as your own site. When
skipping to change at page 16, line 5 skipping to change at page 15, line 12
UPC, shows a geographical map indicating where each LISP site UPC, shows a geographical map indicating where each LISP site
resides. resides.
8. Security Considerations 8. Security Considerations
The use of lig does not affect the security of the LISP The use of lig does not affect the security of the LISP
infrastructure as it is simply a tool that facilities diagnostic infrastructure as it is simply a tool that facilities diagnostic
querying. See [LISP], [ALT], and [LISP-MS] for descriptions of the querying. See [LISP], [ALT], and [LISP-MS] for descriptions of the
security properties of the LISP infrastructure. security properties of the LISP infrastructure.
Lig provides easy access to the information in the public mapping
database. Therefore, it is important to protect the mapping
information for private use. This can be provided by disallowing
access to specific mapping entries or to place such entries in a
private mapping database system.
9. IANA Considerations 9. IANA Considerations
This document makes no request of the IANA. This document makes no request of the IANA.
10. References 10. References
10.1. Normative References 10.1. Normative References
[INTERWORK]
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking LISP with IPv4 and IPv6",
draft-ietf-lisp-interworking-02.txt (work in progress).
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-15.txt (work in progress).
[LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",
draft-ietf-lisp-ms-11.txt (work in progress).
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006. Plan", BCP 122, RFC 4632, August 2006.
10.2. Informative References 10.2. Informative References
[ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP-ALT)", Alternative Topology (LISP-ALT)",
draft-ietfr-lisp-alt-06.txt (work in progress). draft-ietf-lisp-alt-08.txt (work in progress).
[CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
Content distribution Overlay Network Service for LISP", Content distribution Overlay Network Service for LISP",
draft-meyer-lisp-cons-04.txt (work in progress). draft-meyer-lisp-cons-04.txt (work in progress).
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-15.txt (work in progress).
[LISP-LIG] [LISP-LIG]
Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
draft-farinacci-lisp-lig-02.txt (work in progress). draft-farinacci-lisp-lig-02.txt (work in progress).
[LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",
draft-ietf-lisp-ms-10.txt (work in progress).
[NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
draft-lear-lisp-nerd-08.txt (work in progress). draft-lear-lisp-nerd-08.txt (work in progress).
Appendix A. Acknowledgments Appendix A. Acknowledgments
Thanks and kudos to John Zwiebel, Andrew Partan, Darrel Lewis, and Thanks and kudos to John Zwiebel, Andrew Partan, Darrel Lewis, and
Vince Fuller for providing critical feedback on the lig design and Vince Fuller for providing critical feedback on the lig design and
prototype implementations. These folks as well as all the people on prototype implementations. These folks as well as all the people on
lisp-beta@external.cisco.com who tested lig functionality and lisp-beta@external.cisco.com who tested lig functionality and
continue to do so, we extend our sincere thanks. continue to do so, we extend our sincere thanks.
 End of changes. 25 change blocks. 
47 lines changed or deleted 73 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/