wdiff rfc6835.original rfc6835.txt

Network Working Group
Internet Engineering Task Force (IETF) D. Farinacci
Internet-Draft
Request for Comments: 6835 D. Meyer
Intended status: Experimental cisco
Category: Informational Cisco Systems
Expires: March 12, 2012 September 9, 2011

LISP
ISSN: 2070-1721 January 2013

The Locator/ID Separation Protocol Internet Groper (LIG)
draft-ietf-lisp-lig-06

Abstract

A simple tool called the LISP Locator/ID Separation Protocol (LISP)
Internet Groper or 'lig' can be used to query the LISP mapping
database. This draft document describes how it works.

Status of this This Memo

This Internet-Draft document is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents not an Internet Standards Track specification; it is
published for informational purposes.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid 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 maximum candidate for any level of six months Internet
Standard; see Section 2 of RFC 5741.

Information about the current status of this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on March 12, 2012.
http://www.rfc-editor.org/info/rfc6835.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) 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

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3
3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 5
4. Implementation Details . . . . . . . . . . . . . . . . . . . . 9 6
4.1. LISP Router Implementation . . . . . . . . . . . . . . . . 9 6
4.2. Public Domain Host Implementation . . . . . . . . . . . . 10 8
5. Testing the ALT . . . . . . . . . . . . . . . . . . . . . . . 12 9
6. Future Enhancements . . . . . . . . . . . . . . . . . . . . . 13 10
7. Deployed Network Diagnostic Tools . . . . . . . . . . . . . . 14 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.1. 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
10.2. 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 17 11
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 12

1. Introduction

LISP [LISP]

The Locator/ID Separation Protocol [RFC6830] specifies an
architecture and mechanism for replacing the addresses currently used
by IP with two separate name spaces: namespaces: Endpoint IDs (EIDs), used within
sites, and Routing Locators (RLOCs), used on the transit networks
that make up the Internet infrastructure. To achieve this
separation, the Locator/ID
Separation Protocol (LISP) LISP defines protocol mechanisms for mapping from EIDs to
RLOCs. In addition, LISP assumes the existence of a database to
store and propagate those mappings globally. Several such databases
have been proposed, among them: LISP-CONS [CONS],
LISP-NERD [NERD], a Content distribution Overlay
Network Service for LISP [LISP-CONS], a Not-so-novel EID-to-RLOC
Database (LISP-NERD) [RFC6837], and LISP+ALT [ALT], LISP Alternative Topology (LISP+
ALT) [RFC6836], with LISP+ALT being the system that is currently
being implemented and deployed on the pilot LISP network.

In conjunction with the various mapping systems, there exists a
network based
network-based API called LISP Map-Server [LISP-MS]. [RFC6833]. Using Map-
Resolvers and Map-Servers allows LISP sites to query and register
into the database in a uniform way independent of the mapping system
used. Sending Map-Requests to Map-Resolvers provides a secure
mechanism to obtain a Map-Reply containing the authoritative EID-to-
RLOC mapping for a destination LISP site.

The 'lig' is a manual management tool to query the mapping database.
It can be run by all devices which that implement LISP, including ITRs,
ETRs, PITRs, PETRs, Ingress
Tunnel Routers (ITRs), Egress Tunnel Routers (ETRs), Proxy-ITRs,
Proxy-ETRs, Map-Resolvers, Map-Servers, and LISP-ALT routers, Routers, as well
as by a host system at either a LISP-capable or non-LISP-
capable non-LISP-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

Map-Server: a network infrastructure component which that learns EID-to-
RLOC mapping entries from an authoritative source (typically, an
ETR, though static configuration or another out-of-band mechanism
may be used). A Map-Server advertises these mappings in the
distributed mapping database.

Map-Resolver: a network infrastructure component which that accepts LISP
Encapsulated Map-Requests, typically from an ITR, quickly
determines whether or not the destination IP address is part of
the EID namespace; if it is not, a Negative Map-Reply is
immediately returned. Otherwise, the Map-Resolver finds the
appropriate EID-to-RLOC mapping by consulting the distributed
mapping database system.

Routing Locator (RLOC): the IPv4 or IPv6 address of an egress
tunnel router Egress
Tunnel Router (ETR). It is the output of a an EID-to-RLOC mapping
lookup. An EID maps to one or more RLOCs. Typically, RLOCs are
numbered from topologically-aggregatable topologically aggregatable blocks that are assigned
to a site at each point to which it attaches to the global
Internet. Thus, the topology is defined by the connectivity of
provider networks networks, and RLOCs can be thought of as PA Provider-
Assigned (PA) addresses. Multiple RLOCs can be assigned to the
same ETR device or to multiple ETR devices at a site.

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
(most inner) LISP header of a packet. The host obtains a
destination EID the same way it obtains a destination address
today, for example example, through a DNS lookup. The source EID is
obtained via existing mechanisms used to set a host's "local" IP
address. An EID is allocated to a host from an EID-prefix block
associated with the site where the host is located. An EID can be
used by a host to refer to other hosts. EIDs must not be used as
LISP RLOCs. Note that EID blocks may be assigned in a
hierarchical manner, independent of the network topology, to
facilitate scaling of the mapping database. In addition, an EID
block assigned to a site may have site-local structure
(subnetting) for routing within the site; this structure is not
visible to the global routing system.

EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that
stores, tracks, and is responsible for timing-out and otherwise
validating EID-to-RLOC mappings. This cache is distinct from the
full "database" of EID-to-RLOC mappings, it mappings; the cache is dynamic,
local to the ITR(s), and relatively small small, while the database is
distributed, relatively static, and much more global in scope.

EID-to-RLOC Database: a global distributed database that contains
all known EID-prefix to RLOC mappings. Each potential ETR
typically contains a small piece of the database: the EID-to-RLOC
mappings for the EID prefixes "behind" the router. These map to
one of the router's own, globally-visible, IP addresses.

Encapsulated Map-Request (EMR): an EMR is a Map-Request message
which
that is encapsulated with another LISP header using UDP
destination port number 4341. 4342. It is used so an ITR, PITR, or a
system initiating a 'lig' command can get the Map-Request to a
Map-Resolver by using locater locator addresses. When the Map-Request is
decapsulated by the Map-Resolver Map-Resolver, it will be forwarded on the ALT
network to the Map-Server that has injected the EID-prefix for a
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. The
ETR will then return an authoritative reply to the system that
initiated the request. See [LISP] [RFC6830] for packet format details.

Ingress Tunnel Router (ITR): An ITR is a router which that accepts an IP
packet with a single IP header (more precisely, an IP packet that
does not contain a LISP header). The router treats this "inner"
IP destination address as an EID and performs an EID-to-RLOC
mapping lookup. The router then prepends an "outer" IP header
with one of its globally-routable globally routable RLOCs in the source address
field and the result of the mapping lookup in the destination
address field. Note that this destination RLOC may be an
intermediate, proxy device that has better knowledge of the EID-
to-RLOC mapping closer to the destination EID. In general, an ITR
receives IP packets from site end-systems on one side and sends
LISP-encapsulated IP packets toward the Internet on the other
side.

Egress Tunnel Router (ETR): An ETR is a router that accepts an IP
packet where the destination address in the "outer" IP header is
one of its own RLOCs. The router strips the "outer" header and
forwards the packet based on the next IP header found. In
general, an ETR receives LISP-encapsulated IP packets from the
Internet on one side and sends decapsulated IP packets to site
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
of a LISP tunnel as well.

Proxy ITR

Proxy-ITR (PITR): A PITR is PITR, also known as a PTR PTR, is defined and
described in [INTERWORK], a [RFC6832]. A PITR acts like an ITR but does so on
behalf of non-LISP sites which that send packets to destinations at LISP
sites.

Proxy ETR

Proxy-ETR (PETR): A PETR is defined and described in [INTERWORK], a [RFC6832]. A
PETR acts like an ETR but does so on behalf of LISP sites which that
send packets to destinations at non-LISP sites.

xTR: A An 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
router that is the tunnel endpoint. Used endpoint; it is used synonymously with
the term "Tunnel Router". "tunnel router". For example, "An "an xTR can be located at
the Customer Edge (CE) router", meaning router" means that both ITR and ETR
functionality is at the CE router.

Provider Assigned

Provider-Assigned (PA) Addresses: PA addresses are an address block
assigned to a site by each service provider to which a site
connects. Typically, each block is a sub-block of a service service-
provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and
is aggregated into the larger block before being advertised into
the global Internet. Traditionally, IP multihoming has been
implemented by each multi-homed multihomed site acquiring its own, globally- own globally
visible prefix. LISP uses only topologically-assigned topologically assigned and
aggregatable address blocks for RLOCs, eliminating this
demonstrably non-scalable practice.

3. Basic Overview

When the lig 'lig' command is run, a Map-Request is sent for a
destination EID. When a Map-Reply is returned, the contents are
displayed to the user. The information displayed includes:

o The EID-prefix for the site that the queried destination EID
matches.

o The locator address of the Map Replier.

o The locator-set Locator-Set for the mapping entry entry, which includes the locator
address, up/down status, priority, and weight of each locator. Locator.

o An A round-trip-time estimate for the Map-Request/Map-Reply exchange.

A possible syntax for a lig 'lig' command could be:

lig <destination> [source <source>] [to <map-resolver>]
Parameter description:

<destination>: is either a Fully Qualified Domain Name (FQDN) or a
destination EID for a remote LISP site.

source <source>: is an optional source EID to be inserted in the
"Source EID"
'Source EID' field of the Map-Request.

to <map-resolver>: is an optional Fully Qualified Domain Name FQDN or RLOC address for a Map-Resolver. Map-
Resolver.

The lig 'lig' utility has two use cases. The first being is a way to query the
mapping database for a particular EID. And the The other is to verify if a
site has registered successfully with a Map-Server.

The first usage has already been described. Verifying registration
is called "ligging yourself". What occurs is in yourself"; it happens as follows. In the lig 'lig'
initiator, a Map-Request is sent for one of the EIDs for the lig 'lig'
initiator's site. The Map-Request is then returned to one of the
ETRs for the lig
initiating 'lig'-initiating site. In response to the Map-Request,
a Map-Reply is sent back to the locator address of the lig 'lig'
initiator (note the Map-Reply could be sent by the lig 'lig' initiator).
That Map-Reply is processed processed, and the mapping data for the lig 'lig'-
initiating site is displayed for the user. Refer to the syntax in section
Section 4.1 for an implementation of "ligging yourself". However,
for host-based implementations within a LISP site, "lig self" is less
useful since the host may not have an RLOC with which to receive a Map-Reply with.
Map-Reply. But, lig 'lig' can be used in a non-LISP site site, as well as
from infrastructure hosts hosts, to get mapping information.

4. Implementation Details

4.1. LISP Router Implementation

The cisco Cisco LISP prototype implementation has support for lig 'lig' for
IPv4 and IPv6. The command line description is:

lig <dest-eid> [source <source-eid>] [to <mr>] [count <1-5>]

This command initiates the LISP Internet Groper. It is similar to
the DNS analogue 'dig' but works on the LISP mapping database. When
this command is invoked, the local system will send a Map-Request to
the configured Map-Resolver. When a Map-Reply is returned, its
contents will be displayed to the user. By default, up to 3 three Map-
Requests are sent if no Map-Reply is returned but returned, but, once a Map-Reply
is
returned returned, no other Map-Requests are sent. The destination can
take a 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.
Virtual Routing and Forwarding (VRF) table. When <mr> is specified,
then the Map-Request is sent to the address. Otherwise, the Map-Request Map-
Request is sent to a configured Map-Resolver. When a Map-Resolver is
not configured configured, then the Map-Request is sent on 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.

Some sample output:

router# lig abc.example.com
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

Map-cache

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,
via map-reply, auth
Locator Uptime State Priority/Weight Packets In/Out
10.0.0.2 13:59:59 up 1/100 0/14

Using lig 'lig' to "lig yourself" is accomplished with the following
syntax:

lig {self | self6} [source <source-eid>] [to <mr>] [count <1-5>]

Use this command for a simple way to see if the site is registered
with the mapping database system. The destination-EID address for
the Map-Request will be the first configured EID-prefix for the site
(with the host-bits host bits set to 0). For example, if the site's EID-prefix
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 (in this example) example), and the Map-Request is sent to 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
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
into the ALT infrastructure infrastructure, in which case the lig 'lig' Map-Request is
processed by the Map-Resolver, Map-Resolver and propagated through each ALT router ALT-Router
hop to the site's registered Map-Server. Then Then, the Map-Server
returns the Map-Request to the originating site. In which that case, an
xTR at the 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 parameters are described above. Using "lig self6" tests for
registering of IPv6 EID- prefixes. EID-prefixes.

Some sample output for ligging yourself: "ligging yourself":

router# lig self
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

Map-cache

Map-Cache entry for EID 192.168.2.0:
192.168.2.0/24, uptime: 00:00:02, expires: 23:59:57
via map-reply, self
Locator Uptime State Priority/Weight Packets In/Out
10.0.0.3 00:00:02 up 1/100 0/0

router# lig self6
Send loopback map-request to 10.0.0.1 for 2001:db8:1:: ...
Received map-reply from 10::1 with rtt 0.044372 secs

Map-cache

Map-Cache entry for EID 192:168:1:::
2001:db8:1::/48, uptime: 00:00:01, expires: 23:59:58
via map-reply, self
Locator Uptime State Priority/Weight Packets In/Out
10.0.0.3 00:00:01 up 1/100 0/0
2001:db8:ffff::1 00:00:01 up 2/0 0/0

4.2. Public Domain Host Implementation

There is a public domain implementation that can run on any x86 based x86-based
system. The only requirement is that the system that initiates lig 'lig'
must have an address assigned from the locator namespace.

lig [-d] <eid> -m <map-resolver> [-c <count>] [-t <timeout>]

Parameter description:

-d: prints additional protocol debug output.

<eid>: is the destination EID or FQDN of a LISP host.

-m <map-resolver>: is the RLOC address or FQDN of a Map-Resolver.

-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
to 5.

-t <timeout>: the amount of time, in seconds, before another Map-
Request is sent when no Map-Reply is returned. The default value
is 2 seconds. The range is from 1 to 5.

Some sample output:

% lig xyz.example.com -m 10.0.0.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

Mapping entry for EID 192.168.1.1:
192.168.1.0/24, record ttl: 60
Locator State Priority/Weight
10.0.0.1 up 1/25
10.0.0.2 up 1/25
10.0.0.3 up 1/25
10.0.0.4 up 2/25

The public domain implementation of lig 'lig' is available at
http://github.com/davidmeyer/lig.
<http://github.com/LISPmob/lig>.

5. Testing the ALT

There are cases where a Map-Reply is returned from a lig request 'lig' request,
but the user doesn't really know how much of the mapping
infrastructure was tested. There are two cases to consider, consider --
avoiding the ALT and traversing the ALT.

When an ITR sends a lig 'lig' request to its Map-Resolver for a
destination-EID, the Map-Resolver could also be configured as a Map-
Server. And if the destination-EID is for a site that registers with
this Map-Server, the Map-Request is sent to the site directly without
testing the ALT. This occurs because the Map-Server is the source of
the advertisement for the site's EID-prefix. So So, if the map-reply is
returned to the lig requesting 'lig'-requesting site, you cannot be sure that other
sites can reach the same destination-EID.

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
case is testing the functionality of the Map-Resolver, traversal of
the ALT (testing BGP-over-GRE), and the Map-Server.

It is recommended that users issue 2 lig requests, each of which two 'lig' requests; they send
Map-Requests Map-
Requests to different Map-Resolvers.

The network can have a LISP-ALT router Router deployed as a "ALT looking-
glass" node. This type of router has BGP peering sessions with other
ALT routers Routers where it does not inject any EID-prefixes into the ALT
but just learns ones advertised by other ALT routers Routers and Map-Servers.
This router is configured as a Map-Resolver. Lig 'lig' users can point to
the ALT looking-glass router for Map-Resolver services via the "to
<map-resolver>" parameter on the lig 'lig' command. The ALT looking-glass looking-
glass node can be used to lig 'lig' other sites as well as your own site.
When the ALT looking-glass is used as a Map-Resolver, you can be
assured the ALT network is being tested.

6. Future Enhancements

When negative Negative Map-Replies have been further developed and
implemented, lig 'lig' should be modified appropriately to process and
clearly indicate how and why a negative Negative Map-Reply was received.
Negative Map-Replies could be sent in the following cases, cases: the lig 'lig'
request was initiated for a non-EID address or the Map-Request
initiated by lig request is being rejected due to rate-limiting there was rate-
limiting on the replier.

7. Deployed Network Diagnostic Tools

There is an a web-based interface to do auto-polling with lig 'lig' on the
back-end for most of the LISP sites on the LISP test network. The
web-page
web page can be accessed at http://www.lisp4.net/status. <http://www.lisp4.net/status>.

There is a LISP site monitoring web-based interface that can be found
at http://www.lisp4.net/lisp-site. <http://lispmon.net>.

At http://baldomar.ccaba.upc.edu/lispmon, <http://baldomar.ccaba.upc.edu/lispmon>, written by the folks at
UPC,
Universitat Politecnica de Catalunya (UPC), shows a geographical map
indicating where each LISP site resides.

8. Security Considerations

The use of lig 'lig' does not affect the security of the LISP
infrastructure as it is simply a tool that facilities diagnostic
querying. See [LISP], [ALT], [RFC6830], [RFC6836], and [LISP-MS] [RFC6833] for descriptions
of the security properties of the LISP infrastructure.

Lig

'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

This document makes no request of the IANA.

10. References

10.1.

9.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
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.

10.2. Informative References

[ALT]

[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP-ALT)",
draft-ietf-lisp-alt-08.txt (work in progress).

[CONS] "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
January 2013.

[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between the Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, January 2013.

[RFC6833] Farinacci, D. and V. Fuller, "Locator/ID Separation
Protocol (LISP) Map Server Interface", RFC 6833,
January 2013.

9.2. Informative References

[LISP-CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
Content distribution Overlay Network Service for LISP",
draft-meyer-lisp-cons-04.txt (work
Work in progress).

[LISP-LIG] Progress, April 2008.

[RFC6836] Farinacci, D. D., Fuller, V., Meyer, D., and D. Meyer, "LISP Internet Groper (LIG)",
draft-farinacci-lisp-lig-02.txt (work in progress).

[NERD] Lewis,
"Locator/ID Separation Protocol Alternative Topology
(LISP+ALT)", RFC 6836, January 2013.

[RFC6837] Lear, E., "NERD: A Not-so-novel EID Endpoint ID (EID) to RLOC
Routing Locator (RLOC) Database",
draft-lear-lisp-nerd-08.txt (work in progress). RFC 6837,
January 2013.

Appendix A. Acknowledgments

Thanks and kudos to John Zwiebel, Andrew Partan, Darrel Lewis, and
Vince Fuller for providing critical feedback on the lig 'lig' design and
prototype implementations. These folks To these folks, as well as all the people
on lisp-beta@external.cisco.com who tested lig 'lig' functionality and
continue to do so, we extend our sincere thanks.

This working group draft document is based on an individual contribution
draft-farinacci-lisp-lig-02.txt [LISP-LIG]. contribution.

Authors' Addresses

Dino Farinacci
cisco
Cisco Systems
Tasman Drive
San Jose, CA 95134
USA

Email: dino@cisco.com

EMail: farinacci@gmail.com

Dave Meyer
cisco
Cisco Systems
170 Tasman Drive
San Jose, CA
USA

Email:

EMail: dmm@cisco.com