Subject: I-D Action:draft-lear-lisp-nerd-02.txt

From: [email-masked]
Date: Fri, 21 Sep 2007 03:20:02 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : NERD: A Not-so-novel EID to RLOC Database
	Author(s)       : E. Lear
	Filename        : draft-lear-lisp-nerd-02.txt
	Pages           : 30
	Date            : 2007-09-21

LISP is a protocol to encapsulate IP packets in order to allow end
sites to multihome without injecting routes from one end of the
Internet to another.  This memo specifies a database and a method to
transport the mapping of EIDs to RLOCs to routers in a reliable,
scalable, and secure manner.  Our analysis concludes that transport
of of all EID/RLOC mappings scales well to at least 10^8 entries, and
that use of DNS or any approach that queries for mappings has
substantial operational concerns.Table of Contents

1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
  1.1.  Base Assumptions . . . . . . . . . . . . . . . . . . . . .  3
  1.2.  What is NERD?  . . . . . . . . . . . . . . . . . . . . . .  4
  1.3.  Glossary . . . . . . . . . . . . . . . . . . . . . . . . .  5
2.  Theory of Operation  . . . . . . . . . . . . . . . . . . . . .  5
  2.1.  Who are database authorities?  . . . . . . . . . . . . . .  6
3.  NERD Format  . . . . . . . . . . . . . . . . . . . . . . . . .  7
  3.1.  NERD Record Format . . . . . . . . . . . . . . . . . . . .  9
  3.2.  Database Update Format . . . . . . . . . . . . . . . . . . 10
4.  NERD Distribution Mechanism  . . . . . . . . . . . . . . . . . 10
  4.1.  Initial Bootstrap  . . . . . . . . . . . . . . . . . . . . 10
  4.2.  Retrieving Changes . . . . . . . . . . . . . . . . . . . . 10
5.  Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
  5.1.  Database Size  . . . . . . . . . . . . . . . . . . . . . . 12
  5.2.  Router Throughput Versus Time  . . . . . . . . . . . . . . 14
  5.3.  Number of Servers Required . . . . . . . . . . . . . . . . 14
  5.4.  Security Considerations  . . . . . . . . . . . . . . . . . 16

 5.4.1.  Use of Public Key Infrastructures (PKIs) . . . . . . . 17

 5.4.2.  Other Risks  . . . . . . . . . . . . . . . . . . . . . 19
6.  Why not use XML? . . . . . . . . . . . . . . . . . . . . . . . 19
7.  Other Distribution Mechanisms  . . . . . . . . . . . . . . . . 20
  7.1.  What About DNS as a retrieval model? . . . . . . . . . . . 21

 7.1.1.  Perhaps use a hybrid model?  . . . . . . . . . . . . . 22
  7.2.  Use of BGP . . . . . . . . . . . . . . . . . . . . . . . . 23
8.  Deployment Issues  . . . . . . . . . . . . . . . . . . . . . . 23
  8.1.  HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
9.  Conclusions  . . . . . . . . . . . . . . . . . . . . . . . . . 24
10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
11. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 25
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
  12.1. Normative References . . . . . . . . . . . . . . . . . . . 25
  12.2. Informational References . . . . . . . . . . . . . . . . . 26
Appendix A.  Generating and verifying the database signature

 with OpenSSL  . . . . . . . . . . . . . . . . . . . . 27
Appendix B.  Changes . . . . . . . . . . . . . . . . . . . . . . . 28
Appendix C.  Open Questions  . . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 301. 
Introduction

Locator/ID Separation Protocol (LISP) [1] is a protocol whose primary
purpose is to separate an IP address used by a host and local routing
system from the locators advertised by BGP participants on the
Internet in general, and in the default free zone (DFZ) in
particular.  It accomplishes this by establishing a mapping between
globally unique endpoint identifiers (EIDs) and routing locators
(RLOCs) within the global routing table.  This reduces the amount of
state change that occurs on routers within the default-free zone on
the Internet, while enabling end sites to be multihomed.

In early stages of LISP (1 and 1.5) the mapping is either configured
into a device or it is learned via data-triggered control messages
between ingress tunnel routers (ITRs) and egress tunnel routers
(ETRs) under the assumption that during transition, EIDs will be
present within the global routing system, as they are today.

In later stages of LISP, the assumption will be that EIDs are not
contained within the global routing system, but that instead the
mapping from EIDs to RLOCs will be learned through some other means.
This memo addresses different approaches to the problem, and
specifies a Not-so-novel EID RLOC Database (NERD) and methods to both
receive the database and to receive updates.

LISP and NERD are both currently experimental stages.  The NERD
database is specified in such a way that the methods used to
distribute or retrieve it may vary over time.  Multiple databases are
supported in order to allow for multiple data sources.  An effort has
been made to divorce the database from access methods so that both
can evolve independently through experimentation and operational
validation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-lear-lisp-nerd-02.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of 
the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then
	"get draft-lear-lisp-nerd-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-lear-lisp-nerd-02.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce