draft-ietf-lisp-ddt-01.txt   draft-ietf-lisp-ddt-02.txt 
Network Working Group V. Fuller Network Working Group V. Fuller
Internet-Draft D. Lewis Internet-Draft
Intended status: Experimental V. Ermagan Intended status: Experimental D. Lewis
Expires: September 29, 2013 cisco Systems Expires: April 16, 2015 V. Ermagan
Cisco Systems
A. Jain A. Jain
Juniper Networks Juniper Networks
March 28, 2013 October 13, 2014
LISP Delegated Database Tree LISP Delegated Database Tree
draft-ietf-lisp-ddt-01.txt draft-ietf-lisp-ddt-02.txt
Abstract Abstract
This draft describes the LISP Delegated Database Tree (LISP-DDT), a This draft describes the LISP Delegated Database Tree (LISP-DDT), a
hierarchical, distributed database which embodies the delegation of hierarchical, distributed database which embodies the delegation of
authority to provide mappings from LISP Endpoint Identifiers (EIDs) authority to provide mappings from LISP Endpoint Identifiers (EIDs)
to Routing Locators (RLOCs). It is a statically-defined distribution to Routing Locators (RLOCs). It is a statically-defined distribution
of the EID namespace among a set of LISP-speaking servers, called DDT of the EID namespace among a set of LISP-speaking servers, called DDT
nodes. Each DDT node is configured as "authoritative" for one or nodes. Each DDT node is configured as "authoritative" for one or
more EID-prefixes, along with the set of RLOCs for Map Servers or more EID-prefixes, along with the set of RLOCs for Map Servers or
skipping to change at page 1, line 40 skipping to change at page 1, line 41
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 29, 2013. This Internet-Draft will expire on April 16, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 21 skipping to change at page 2, line 22
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. Database organization . . . . . . . . . . . . . . . . . . . . 6 3. Database organization . . . . . . . . . . . . . . . . . . . . 6
3.1. EID-prefix tree structure and instance IDs . . . . . . . 6 3.1. EID-prefix tree structure and instance IDs . . . . . . . 6
3.2. Configuring prefix delegation . . . . . . . . . . . . . . 7 3.2. Configuring prefix delegation . . . . . . . . . . . . . . 7
3.2.1. The root DDT node . . . . . . . . . . . . . . . . . . 7 3.2.1. The root DDT node . . . . . . . . . . . . . . . . . . 7
4. The Map-Referral message . . . . . . . . . . . . . . . . . . 7 4. The Map-Referral message . . . . . . . . . . . . . . . . . . 7
4.1. Action codes . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Action codes . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Referral Set . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Referral set . . . . . . . . . . . . . . . . . . . . . . 8
4.3. Incomplete flag . . . . . . . . . . . . . . . . . . . . . 9 4.3. Incomplete flag . . . . . . . . . . . . . . . . . . . . . 9
5. DDT network elements and their operation . . . . . . . . . . 9 5. DDT network elements and their operation . . . . . . . . . . 9
5.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 9 5.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 9
5.1.2. Missing delegation from an authoritative prefix . . . 10 5.1.2. Missing delegation from an authoritative prefix . . . 10
5.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . 10 5.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . 10
5.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . 10 5.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . 10
5.3.1. Queuing and sending DDT Map-Requests . . . . . . . . 10 5.3.1. Queuing and sending DDT Map-Requests . . . . . . . . 10
5.3.2. Receiving and following referrals . . . . . . . . . . 11 5.3.2. Receiving and following referrals . . . . . . . . . . 11
5.3.3. Handling referral errors . . . . . . . . . . . . . . 13 5.3.3. Handling referral errors . . . . . . . . . . . . . . 13
5.3.4. Referral loop detection . . . . . . . . . . . . . . . 13 5.3.4. Referral loop detection . . . . . . . . . . . . . . . 13
6. Psuedo Code and Decision Tree diagrams . . . . . . . . . . . 14 6. Pseudo Code and Decision Tree diagrams . . . . . . . . . . . 14
6.1. Map Resolver processing of ITR Map-Request . . . . . . . 14 6.1. Map Resolver processing of ITR Map-Request . . . . . . . 14
6.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 14 6.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 14
6.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 14 6.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 14
6.2. Map Resolver processing of Map-Referral message . . . . . 16 6.2. Map Resolver processing of Map-Referral message . . . . . 15
6.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 16 6.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 15
6.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 18 6.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 17
6.3. DDT Node processing of DDT Map-Request message . . . . . 20 6.3. DDT Node processing of DDT Map-Request message . . . . . 19
6.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 20 6.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 19
6.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 20 6.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 19
7. Example topology and request/referral following . . . . . . . 21 7. Example topology and request/referral following . . . . . . . 20
7.1. Lookup of 10.1.1.1/32 by ITR1 . . . . . . . . . . . . . . 23 7.1. Lookup of 10.1.1.1/32 by ITR1 . . . . . . . . . . . . . . 22
7.2. Lookup of 10.17.8.1/32 by ITR2 . . . . . . . . . . . . . 24 7.2. Lookup of 10.17.8.1/32 by ITR2 . . . . . . . . . . . . . 23
7.3. Lookup of 10.2.2.2/32 by ITR1 . . . . . . . . . . . . . . 25 7.3. Lookup of 10.2.2.2/32 by ITR1 . . . . . . . . . . . . . . 24
7.4. Lookup of 10.16.2.1/32 by ITR2 . . . . . . . . . . . . . 25 7.4. Lookup of 10.16.2.1/32 by ITR2 . . . . . . . . . . . . . 24
7.5. Lookup of 10.16.0.1/32 (non-existant EID) by ITR2 . . . . 26 7.5. Lookup of 10.16.0.1/32 (non-existant EID) by ITR2 . . . . 25
8. Securing the database and message exchanges . . . . . . . . . 27 8. Securing the database and message exchanges . . . . . . . . . 25
8.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . 27 8.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . 26
8.2. DDT node operation . . . . . . . . . . . . . . . . . . . 28 8.2. DDT node operation . . . . . . . . . . . . . . . . . . . 26
8.2.1. DDT public key revocation . . . . . . . . . . . . . . 28 8.2.1. DDT public key revocation . . . . . . . . . . . . . . 27
8.3. Map Server operation . . . . . . . . . . . . . . . . . . 28 8.3. Map Server operation . . . . . . . . . . . . . . . . . . 27
8.4. Map Resolver operation . . . . . . . . . . . . . . . . . 29 8.4. Map Resolver operation . . . . . . . . . . . . . . . . . 27
9. Open Issues and Considerations . . . . . . . . . . . . . . . 29 9. Open Issues and Considerations . . . . . . . . . . . . . . . 28
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
11. Security Considerations . . . . . . . . . . . . . . . . . . . 30 11. Security Considerations . . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.1. Normative References . . . . . . . . . . . . . . . . . . 31 12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 31 12.2. Informative References . . . . . . . . . . . . . . . . . 30
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 32 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 30
Appendix B. Map-Referral Message Format . . . . . . . . . . . . 32 Appendix B. Map-Referral Message Format . . . . . . . . . . . . 31
B.1. SIG section . . . . . . . . . . . . . . . . . . . . . . . 34 B.1. SIG section . . . . . . . . . . . . . . . . . . . . . . . 33
Appendix C. Encapsulated Control Message Format . . . . . . . . 35 Appendix C. Encapsulated Control Message Format . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
LISP [RFC6830] specifies an architecture and mechanism for replacing LISP [RFC6830] specifies an architecture and mechanism for replacing
the addresses currently used by IP with two separate name spaces: the addresses currently used by IP with two separate name spaces:
relatively static Endpoint Identifiers (EIDs), used end-to-end for relatively static Endpoint Identifiers (EIDs), used end-to-end for
terminating transport-layer associations, and Routing Locators terminating transport-layer associations, and Routing Locators
(RLOCs), which are more dynamic, are bound to topological location, (RLOCs), which are more dynamic, are bound to topological location,
and are used for routing and forwarding through the Internet and are used for routing and forwarding through the Internet
infrastructure. infrastructure.
skipping to change at page 3, line 48 skipping to change at page 3, line 49
The term "Extended EID" (XEID) is also used for an individual LISP The term "Extended EID" (XEID) is also used for an individual LISP
EID that is further qualified through the use of an Instance ID. See EID that is further qualified through the use of an Instance ID. See
[LCAF] for further discussion of the use of Instance IDs. [LCAF] for further discussion of the use of Instance IDs.
The DBID is provided for possible use in case a need evolves for The DBID is provided for possible use in case a need evolves for
another, higher level in the hierarchy, to allow the creation of another, higher level in the hierarchy, to allow the creation of
multiple, separate database trees. multiple, separate database trees.
LISP-DDT is a hierarchical distributed database which embodies the LISP-DDT is a hierarchical distributed database which embodies the
delegation of authority to provide mappings, i.e. its internal delegation of authority to provide mappings, i.e. its internal
structure mirrors the hierarchical delegation of address space. It structure mirrors the hierarchical delegation of address space. It
also provides delegation information to Map Resolvers, which use the also provides delegation information to Map Resolvers, which use the
information to locate EID-to-RLOC mappings. A Map Resolver which information to locate EID-to-RLOC mappings. A Map Resolver which
needs to locate a given mapping will follow a path through the tree- needs to locate a given mapping will follow a path through the tree-
structured database, contacting, one after another, the DDT nodes structured database, contacting, one after another, the DDT nodes
along that path until it reaches the leaf DDT node(s) authoritative along that path until it reaches the leaf DDT node(s) authoritative
for the mapping it is seeking. for the mapping it is seeking.
LISP-DDT defines a new device type, the DDT node, that is configured LISP-DDT defines a new device type, the DDT node, that is configured
as authoritative for one or more XEID-prefixes. It also is as authoritative for one or more XEID-prefixes. It also is
configured with the set of more-specific sub-prefixes that are configured with the set of more-specific sub-prefixes that are
further delegated to other DDT nodes. To delegate a sub-prefix, the further delegated to other DDT nodes. To delegate a sub-prefix, the
"parent" DDT node is configured with the RLOCs of each child DDT node "parent" DDT node is configured with the RLOCs of each child DDT node
that is authoritative for the sub-prefix. Each RLOC either points to that is authoritative for the sub-prefix. Each RLOC either points to
a Map Server (sometimes termed a "terminal DDT node") to which an a Map Server (sometimes termed a "terminal DDT node") to which an
Egress Tunnel Routers (ETRs) has registered that sub-prefix or points Egress Tunnel Routers (ETRs) has registered that sub-prefix or points
to another DDT node in the database tree that further delegates the to another DDT node in the database tree that further delegates the
sub-prefix. See LISP-MS [RFC6833] for a description of the sub-prefix. See [RFC6833] for a description of the functionality of
functionality of the Map Server and Map Resolver. Note that the the Map Server and Map Resolver. Note that the target of a
target of a delegation must always be an RLOC (not an EID) to avoid delegation must always be an RLOC (not an EID) to avoid any circular
any circular dependency. dependency.
To provide a mechanism for traversing the database tree, LISP-DDT To provide a mechanism for traversing the database tree, LISP-DDT
defines a new LISP message type, the Map-Referral, which is returned defines a new LISP message type, the Map-Referral, which is returned
to the sender of a Map-Request when the receiving DDT node can refer to the sender of a Map-Request when the receiving DDT node can refer
the sender to another DDT node that has more detailed information. the sender to another DDT node that has more detailed information.
See Section 4 for the definition of the Map-Referral message. See Section 4 for the definition of the Map-Referral message.
To find an EID-to-RLOC mapping, a LISP-DDT client, usually a DDT Map To find an EID-to-RLOC mapping, a LISP-DDT client, usually a DDT Map
Resolver, starts by sending an Encapsulated Map-Request to a Resolver, starts by sending an Encapsulated Map-Request to a
preconfigured DDT node RLOC. The DDT node responds with a Map- preconfigured DDT node RLOC. The DDT node responds with a Map-
skipping to change at page 4, line 45 skipping to change at page 4, line 46
information; in the latter case, the DDT node then sends a new information; in the latter case, the DDT node then sends a new
Encapsulated Map-Request to the next DDT node and the process repeats Encapsulated Map-Request to the next DDT node and the process repeats
in an iterative manner. in an iterative manner.
Conceptually, this is similar to the way that a client of the Domain Conceptually, this is similar to the way that a client of the Domain
Name System (DNS) follows referrals (DNS responses that contain only Name System (DNS) follows referrals (DNS responses that contain only
NS records) from a series of DNS servers until it finds an answer. NS records) from a series of DNS servers until it finds an answer.
2. Definition of Terms 2. Definition of Terms
Extended EID (XEID): a LISP EID, optionally extended with a non- Extended EID (XEID): a LISP EID, optionally extended with a non-
zero Instance ID (IID) if the EID is intended for use in a context zero Instance ID (IID) if the EID is intended for use in a context
where it may not be a unique value, such as on a Virtual Private where it may not be a unique value, such as on a Virtual Private
Network where [RFC1918] address space is used. See "Using Network where [RFC1918] address space is used. See "Using
Virtualization and Segmentation with LISP" in [RFC6830] for more Virtualization and Segmentation with LISP" in [RFC6830] for more
discussion of Instance IDs. discussion of Instance IDs.
XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT DBID (provided XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT DBID (provided
to allow the definition of multiple databases; currently always to allow the definition of multiple databases; currently always
zero in this version of DDT, with other values reserved for future zero in this version of DDT, with other values reserved for future
use), 32-bit IID and 16-bit AFI prepended. An XEID-prefix is used use), 32-bit IID and 16-bit AFI prepended. An XEID-prefix is used
as a key index into the database. as a key index into the database.
DDT node: a network infrastructure component responsible for DDT node: a network infrastructure component responsible for
specific XEID-prefix and for delegation of more-specific sub- specific XEID-prefix and for delegation of more-specific sub-
prefixes to other DDT nodes. prefixes to other DDT nodes.
DDT client: a network infrastructure component that sends Map- DDT client: a network infrastructure component that sends Map-
Request messages and implements the iterative following of Map- Request messages and implements the iterative following of Map-
Referral results. Typically, a DDT client will be a Map Resolver Referral results. Typically, a DDT client will be a Map Resolver
but it is also possible for an ITR to implement DDT client but it is also possible for an ITR to implement DDT client
functionality. functionality.
DDT Map Server: a DDT node that also implements Map Server DDT Map Server: a DDT node that also implements Map Server
functionality (forwarding Map-Requests and/or returning Map- functionality (forwarding Map-Requests and/or returning Map-
Replies if offering proxy Map-Reply service) for a subset of its Replies if offering proxy Map-Reply service) for a subset of its
delegated prefixes. delegated prefixes.
DDT Map Resolver: a network infrastructure element that accepts a DDT Map Resolver: a network infrastructure element that accepts a
Map-Request, adds the XEID to its pending request list, then Map-Request, adds the XEID to its pending request list, then
queries one or more DDT nodes for the requested EID, following queries one or more DDT nodes for the requested EID, following
returned referrals until it receives one with action code MS-ACK returned referrals until it receives one with action code MS-ACK
(or an error indication). MS-ACK indicates that the Map-Request (or an error indication). MS-ACK indicates that the Map-Request
has been sent to a Map Server that will forward it to an ETR that, has been sent to a Map Server that will forward it to an ETR that,
in turn, will provide a Map-Reply to the original sender. A DDT in turn, will provide a Map-Reply to the original sender. A DDT
Map Resolver maintains both a cache of Map-Referral message Map Resolver maintains both a cache of Map-Referral message
results containing RLOCs for DDT nodes responsible for XEID- results containing RLOCs for DDT nodes responsible for XEID-
prefixes of interest (termed the "referral cache") a pending prefixes of interest (termed the "referral cache") a pending
request list of XEIDs that are being resolved through iterative request list of XEIDs that are being resolved through iterative
querying of DDT nodes. querying of DDT nodes.
Encapsulated Map-Request: a LISP Map-Request carried within an Encapsulated Map-Request: a LISP Map-Request carried within an
Encapsulated Control Message, which has an additional LISP header Encapsulated Control Message, which has an additional LISP header
prepended. Sent to UDP destination port 4342. The "outer" prepended. Sent to UDP destination port 4342. The "outer"
addresses are globally-routable IP addresses, also known as RLOCs. addresses are globally-routable IP addresses, also known as RLOCs.
Used by an ITR when sending to a Map Resolver and by a Map Server Used by an ITR when sending to a Map Resolver and by a Map Server
when forwarding a Map-Request to an ETR as documented in LISP-MS when forwarding a Map-Request to an ETR as documented in LISP-MS
[RFC6833]. [RFC6833].
DDT Map-Request: an Encapsulated Map-Request sent by a DDT client DDT Map-Request: an Encapsulated Map-Request sent by a DDT client to
to a DDT node. The "DDT-originated" flag is set in the a DDT node. The "DDT-originated" flag is set in the encapsulation
encapsulation header indicating that the DDT node should return header indicating that the DDT node should return Map-Referral
Map-Referral messages if the Map-Request EID matches a delegated messages if the Map-Request EID matches a delegated XEID-prefix
XEID-prefix known to the DDT node. Section 5.3.1 describes how known to the DDT node. Section 5.3.1 describes how DDT Map-
DDT Map-Requests are sent. Requests are sent.
Authoritative XEID-prefix: an XEID-prefix delegated to a DDT node Authoritative XEID-prefix: an XEID-prefix delegated to a DDT node
and for which the DDT node may provide further delegations of and for which the DDT node may provide further delegations of
more-specific sub-prefixes. more-specific sub-prefixes.
Map-Referral: a LISP message sent by a DDT node in response to a Map-Referral: a LISP message sent by a DDT node in response to a DDT
DDT Map-Request for an XEID that matches a configured XEID-prefix Map-Request for an XEID that matches a configured XEID-prefix
delegation. A non-negative Map-Referral includes a "referral", a delegation. A non-negative Map-Referral includes a "referral", a
set of RLOCs for DDT nodes that have more information about the set of RLOCs for DDT nodes that have more information about the
sub-prefix; a DDT client "follows the referral" by sending another sub-prefix; a DDT client "follows the referral" by sending another
DDT Map-Request to one of those RLOCs to obtain either an answer DDT Map-Request to one of those RLOCs to obtain either an answer
or another referral to DDT nodes responsible for a more-specific or another referral to DDT nodes responsible for a more-specific
XEID-prefix. See Section 5.1 and Section 5.3.2 for details on the XEID-prefix. See Section 5.1 and Section 5.3.2 for details on the
sending and processing of Map-Referral messages. sending and processing of Map-Referral messages.
negative Map-Referral: a Map-Referral sent in response to a DDT negative Map-Referral: a Map-Referral sent in response to a DDT Map-
Map-Request that matches an authoritative XEID-prefix but for Request that matches an authoritative XEID-prefix but for which
which there is no delegation configured (or no ETR registration if there is no delegation configured (or no ETR registration if sent
sent by a DDT Map-Server). by a DDT Map-Server).
Pending Request List: the set of outstanding requests for which a Pending Request List: the set of outstanding requests for which a
DDT Map Resolver has received encapsulated Map-Requests from a DDT DDT Map Resolver has received encapsulated Map-Requests from a DDT
client for an XEID. Each entry in the list contains additional client for an XEID. Each entry in the list contains additional
state needed by the referral following process, including the state needed by the referral following process, including the
requestor(s) of the XEID (typically, one or more ITRs), saved requestor(s) of the XEID (typically, one or more ITRs), saved
information about the last referral received and followed information about the last referral received and followed
(matching XEID-prefix, action code, RLOC set, index of last RLOC (matching XEID-prefix, action code, RLOC set, index of last RLOC
queried in the RLOC set), and any [LISP-SEC] information that was queried in the RLOC set), and any [LISP-SEC] information that was
included in the DDT client Map-Request. An entry in the list may included in the DDT client Map-Request. An entry in the list may
be interchangeably termed a "pending request list entry" or simply be interchangeably termed a "pending request list entry" or simply
a "pending request". a "pending request".
skipping to change at page 8, line 45 skipping to change at page 8, line 45
DELEGATION-HOLE (4): indicates that the requested XEID matches a DELEGATION-HOLE (4): indicates that the requested XEID matches a
non-delegated sub-prefix of the XEID space. This is a non-LISP non-delegated sub-prefix of the XEID space. This is a non-LISP
"hole", which has not been delegated to any DDT Map Server or ETR. "hole", which has not been delegated to any DDT Map Server or ETR.
See Section 5.1.2 for details. See Section 5.1.2 for details.
NOT-AUTHORITATIVE (5): indicates that the replying DDT node received NOT-AUTHORITATIVE (5): indicates that the replying DDT node received
a Map-Request for an XEID-request for which it is not a Map-Request for an XEID-request for which it is not
authoritative. This can occur if a cached referral has become authoritative. This can occur if a cached referral has become
invalid due to a change in the database hierarchy. invalid due to a change in the database hierarchy.
4.2. Referral Set 4.2. Referral set
For "positive" action codes (NODE-REFERRAL, MS-REFERRAL, MS-ACK), a For "positive" action codes (NODE-REFERRAL, MS-REFERRAL, MS-ACK), a
DDT node includes in the Map-Referral message a list of RLOCs for all DDT node includes in the Map-Referral message a list of RLOCs for all
DDT nodes that are authoritative for the XEID-prefix being returned; DDT nodes that are authoritative for the XEID-prefix being returned;
a DDT Map Resolver uses this information to contact one of those DDT a DDT Map Resolver uses this information to contact one of those DDT
nodes as it "follows" a referral. nodes as it "follows" a referral.
4.3. Incomplete flag 4.3. Incomplete flag
A DDT node sets the "Incomplete" flag in a Map-Referral message if A DDT node sets the "Incomplete" flag in a Map-Referral message if
skipping to change at page 14, line 17 skipping to change at page 14, line 15
Note that when a DDT Map Resolver adds an entry to its lookup queue Note that when a DDT Map Resolver adds an entry to its lookup queue
and sends an initial Map-Request for an XEID, the queue entry has no and sends an initial Map-Request for an XEID, the queue entry has no
previous referral XEID-prefix; this means that the first DDT node previous referral XEID-prefix; this means that the first DDT node
contacted by a DDT Map Resolver may provide a referral to anywhere in contacted by a DDT Map Resolver may provide a referral to anywhere in
the DDT hierarchy. This, in turn, allows a DDT Map Resolver to use the DDT hierarchy. This, in turn, allows a DDT Map Resolver to use
essentially any DDT node RLOCs for its initial cache entries and essentially any DDT node RLOCs for its initial cache entries and
depend on the initial referral to provide a good starting point for depend on the initial referral to provide a good starting point for
Map-Requests; there is no need to configure the same set of root DDT Map-Requests; there is no need to configure the same set of root DDT
nodes on all DDT Map Resolvers. nodes on all DDT Map Resolvers.
6. Psuedo Code and Decision Tree diagrams 6. Pseudo Code and Decision Tree diagrams
To aid in implementation, each of the major DDT Map Server and DDT To aid in implementation, each of the major DDT Map Server and DDT
Map Resolver functions are described below, first using simple Map Resolver functions are described below, first using simple
"psuedo-code" and then in the form of a decision tree. "pseudo-code" and then in the form of a decision tree.
6.1. Map Resolver processing of ITR Map-Request 6.1. Map Resolver processing of ITR Map-Request
6.1.1. Pseudo-code summary 6.1.1. Pseudo-code summary
if ( request pending i.e., (ITR,EID) of request same ) { if ( request pending i.e., (ITR,EID) of request same ) {
replace old request with new & use new request nonce replace old request with new & use new request nonce
for future requests for future requests
} else if ( no match in refcache ) { } else if ( no match in refcache ) {
return negative map-reply to ITR return negative map-reply to ITR
} else if ( match type delegation hole ) { } else if ( match type delegation hole ) {
return negative map-reply to ITR return negative map-reply to ITR
} else if ( match type ms-ack ) { } else if ( match type ms-ack ) {
fwd DDT request to map-server fwd DDT request to map-server
} else { } else {
store & fwd DDT request w/o OTK to node delegation store & fwd DDT request w/o OTK to node delegation
} }
6.1.2. Decision tree diagram 6.1.2. Decision tree diagram
+------------+ +------------+
| Is Request | Yes | Is Request | Yes
| |----> Replace old request with | |----> Replace old request with
| Pending? | new nonce for future requests | Pending? | new nonce for future requests
+------------+ +------------+
| |
|No |No
| |
V V
+------------+ +------------+
skipping to change at page 16, line 9 skipping to change at page 15, line 47
|No |No
| |
V V
Store request & Fwd DDT Request w/o OTK Store request & Fwd DDT Request w/o OTK
to DDT node delegation to DDT node delegation
6.2. Map Resolver processing of Map-Referral message 6.2. Map Resolver processing of Map-Referral message
6.2.1. Pseudo-code summary 6.2.1. Pseudo-code summary
if ( no request pending matched by referral nonce ) { if ( no request pending matched by referral nonce ) {
silently drop silently drop
} }
if ( pfx in referral less specific than last referral used ) { if ( pfx in referral less specific than last referral used ) {
if ( gone through root ) { if ( gone through root ) {
silently drop silently drop
} else { } else {
goto root goto root
} }
} }
switch (map_referral_type) { switch (map_referral_type) {
case NOT_AUTHORITATIVE : case NOT_AUTHORITATIVE :
if ( gone through root ) { if ( gone through root ) {
return negative map-reply to ITR return negative map-reply to ITR
} else { } else {
goto root goto root
} }
case DELEGATION_HOLE: case DELEGATION_HOLE:
cache & send negative map-reply to ITR cache & send negative map-reply to ITR
case MS_REFERRAL: case MS_REFERRAL:
if ( referral equal to last used ) { if ( referral equal to last used ) {
if ( gone through root ) { if ( gone through root ) {
return negative map-reply to ITR return negative map-reply to ITR
} else { } else {
goto root goto root
} }
} else { } else {
cache & follow the referral cache & follow the referral
} }
case NODE_REFERRAL: case NODE_REFERRAL:
if ( referral equal to last used ) { if ( referral equal to last used ) {
if ( gone through root ) { if ( gone through root ) {
return negative map-reply to ITR return negative map-reply to ITR
} else { } else {
goto root goto root
} }
} else { } else {
cache & follow the referral cache & follow the referral
}
} case MS_ACKNOWLEDGEMENT:
if ( OTK stripped ) {
if ( incomplete ) {
resend request with OTK
} else {
cache & resend request with OTK
}
case MS_ACKNOWLEDGEMENT: }
if ( OTK stripped ) {
if ( incomplete ) {
resend request with OTK
} else {
cache & resend request with OTK
}
}
case MS_NOT_REGISTERED: case MS_NOT_REGISTERED:
if { all map-server delegations not tried } { if { all map-server delegations not tried } {
follow delegations not tried follow delegations not tried
if ( !incomplete ) { if ( !incomplete ) {
cache cache
} }
} else { } else {
send negative map-reply to ITR send negative map-reply to ITR
if { !incomplete } { if { !incomplete } {
cache cache
} }
} }
case DEFAULT: case DEFAULT:
drop drop
} }
} }
6.2.2. Decision tree diagram 6.2.2. Decision tree diagram
+------------+ +------------+
| Is Request | No | Is Request | No
| Pending? |----> Silently drop | Pending? |----> Silently drop
+------------+ +------------+
| Yes | Yes
V V
+------------------------------+ Yes +------------------------------+ Yes
| Pfx less specific than last? |----> Silently drop | Pfx less specific than last? |----> Silently drop
+------------------------------+ +------------------------------+
|No |No
V V
+---------------------------------------------------+ +---------------------------------------------------+
| What is Map-Referral Type? |--UNKNOWN-+ | What is Map-Referral Type? |--UNKNOWN-+
+---------------------------------------------------+ | +---------------------------------------------------+ |
| | | | | | V | | | | | | V
| | | | | DEL_HOLE DROP | | | | | DEL_HOLE DROP
| | | | MS_ACK | | | | | MS_ACK |
| | | | | V | | | | | V
| | MS_REF NODE_REF | Cache & return | | MS_REF NODE_REF | Cache & return
| | | | V negative map-reply | | | | V negative map-reply
| | | | +---------+ | | | | +---------+
| NOT_AUTH | | | Was OTK | Yes | NOT_AUTH | | | Was OTK | Yes
| | | | |Stripped?|----> Done | | | | |Stripped?|----> Done
| | V V +---------+ | | V V +---------+
| | +------------+ | No | | +------------+ | No
| | Yes | Pfx equal | V | | Yes | Pfx equal | V
MS_NOT_REGISTERED | +---| to last | +------------+ MS_NOT_REGISTERED | +---| to last | +------------+
| | | | used? | | Incomplete | Yes | | | | used? | | Incomplete | Yes
| | | +------------+ | bit set? |---> Resend DDT | | | +------------+ | bit set? |---> Resend DDT
| V V |No +------------+ request | V V |No +------------+ request
| +------------+ | |No with OTK | +------------+ | |No with OTK
| | Gone | V | | | Gone | V |
| | Through | Cache & follow V | | Through | Cache & follow V
| | Root? | the referral Cache & resend DDT | | Root? | the referral Cache & resend DDT
| +------------+ request with OTK | +------------+ request with OTK
| |No |Yes | |No |Yes
| | | | | |
| V V | V V
| Goto root Send negative map-reply | Goto root Send negative map-reply
V V
+-----------+ Yes +-----------+ Yes +-----------+ Yes +-----------+ Yes
| Other MS |-----Follow other MS-------->|Incomplete |----> Dont cache | Other MS |-----Follow other MS-------->|Incomplete |----> Dont cache
| not tried?| |bit set? | | not tried?| |bit set? |
| |----Send negative map-reply->| |----> Cache | |----Send negative map-reply->| |----> Cache
+-----------+ No +-----------+ No +-----------+ No +-----------+ No
6.3. DDT Node processing of DDT Map-Request message 6.3. DDT Node processing of DDT Map-Request message
6.3.1. Pseudo-code summary 6.3.1. Pseudo-code summary
if ( I am not authoritative ) { if ( I am not authoritative ) {
send map-referral NOT_AUTHORITATIVE with send map-referral NOT_AUTHORITATIVE with
incomplete bit set and ttl 0 incomplete bit set and ttl 0
} else if ( delegation exists ) { } else if ( delegation exists ) {
if ( delegated map-servers ) { if ( delegated map-servers ) {
send map-referral MS_REFERRAL with send map-referral MS_REFERRAL with
ttl 'Default_DdtNode_Ttl' ttl 'Default_DdtNode_Ttl'
} else { } else {
send map-referral NODE_REFERRAL with send map-referral NODE_REFERRAL with
ttl 'Default_DdtNode_Ttl' ttl 'Default_DdtNode_Ttl'
} }
} else { } else {
if ( eid in site) { if ( eid in site) {
if ( site registered ) { if ( site registered ) {
forward map-request to etr forward map-request to etr
if ( map-server peers configured ) { if ( map-server peers configured ) {
send map-referral MS_ACKNOWLEDGEMENT with send map-referral MS_ACKNOWLEDGEMENT with
ttl 'Default_Registered_Ttl' ttl 'Default_Registered_Ttl'
} else { } else {
send map-referral MS_ACKNOWLEDGEMENT with send map-referral MS_ACKNOWLEDGEMENT with
ttl 'Default_Registered_Ttl' and incomplete bit set ttl 'Default_Registered_Ttl' and incomplete bit set
} }
} else { } else {
if ( map-server peers configured ) { if ( map-server peers configured ) {
send map-referral MS_NOT_REGISTERED with send map-referral MS_NOT_REGISTERED with
ttl 'Default_Configured_Not_Registered_Ttl' ttl 'Default_Configured_Not_Registered_Ttl'
} else { } else {
send map-referral MS_NOT_REGISTERED with send map-referral MS_NOT_REGISTERED with
ttl 'Default_Configured_Not_Registered_Ttl' ttl 'Default_Configured_Not_Registered_Ttl'
and incomplete bit set and incomplete bit set
} }
} }
} else { } else {
send map-referral DELEGATION_HOLE with send map-referral DELEGATION_HOLE with
ttl 'Default_Negative_Referral_Ttl' ttl 'Default_Negative_Referral_Ttl'
} }
} }
6.3.2. Decision tree diagram 6.3.2. Decision tree diagram
+------------+
+------------+ | Am I | No
| Am I | No | Authori- |----> Return NOT_AUTHORITATIVE
| Authori- |----> Return NOT_AUTHORITATIVE | tative? | Incomplete = 1
| tative? | Incomplete = 1 +------------+ ttl = Default_DdtNode_Ttl
+------------+ ttl = Default_DdtNode_Ttl |
| |Yes
|Yes |
| V
V +------------+ +------------+
+------------+ +------------+ | Delegation | Yes | Delegations| Yes
| Delegation | Yes | Delegations| Yes | Exists? |---->| are map |----> Return MS_REFERRAL
| Exists? |---->| are map |----> Return MS_REFERRAL | | | servers? | ttl = Default_DdtNode_Ttl
| | | servers? | ttl = Default_DdtNode_Ttl +------------+ +------------+
+------------+ +------------+ | \ No
| \ No |No +--> Return NODE_REFERRAL
|No +--> Return NODE_REFERRAL | ttl = Default_DdtNode_Ttl
| ttl = Default_DdtNode_Ttl V
V +------------+ +------------+ +------------+
+------------+ +------------+ +------------+ | EID in | Yes | Site | Yes | Map-server |
| EID in | Yes | Site | Yes | Map-server | | Site |---->| Registered?|----> Forward---->| peers |
| Site |---->| Registered?|----> Forward---->| peers | | Config? | | | Map-request | configured?|
| Config? | | | Map-request | configured?| +------------+ +------------+ to ETR +------------+
+------------+ +------------+ to ETR +------------+ | | | |
| | | | | |No No| |Yes
| |No No| |Yes | | | |
| | | | | | V V
| | V V | | Return MS_ACK Return MS_ACK
| | Return MS_ACK Return MS_ACK | V with INC=1
| V with INC=1 | +------------+ ttl=Default_Registered_Ttl
| +------------+ ttl=Default_Registered_Ttl | | Map-server | Yes
| | Map-server | Yes | | peers |----> Return MS_NOT_REGISTERED
| | peers |----> Return MS_NOT_REGISTERED | | configured?| ttl = Default_Negative_Referral_Ttl
| | configured?| ttl = Default_Negative_Referral_Ttl | +------------+
| +------------+ | \ No
| \ No |No +--> Return MS_NOT_REGISTERED
|No +--> Return MS_NOT_REGISTERED | Incomplete = 1
| Incomplete = 1 V ttl = Default_Negative_Referral_Ttl
V ttl = Default_Negative_Referral_Ttl Return DELEGATION_HOLE
Return DELEGATION_HOLE ttl = Default_Negative_Referral_Ttl
ttl = Default_Negative_Referral_Ttl
7. Example topology and request/referral following 7. Example topology and request/referral following
To show how referrals are followed to find the RLOCs for a number of To show how referrals are followed to find the RLOCs for a number of
EIDs, consider the following example EID topology for DBID=0, IID=0, EIDs, consider the following example EID topology for DBID=0, IID=0,
AFI=1, and EID=0/0 AFI=1, and EID=0/0
+---------------------+ +---------------------+ +---------------------+ +---------------------+
| root1: 192.0.2.1 | | root2: 192.0.2.2 | | root1: 192.0.2.1 | | root2: 192.0.2.2 |
| authoritative: 0/0 | | authoritative: 0/0 | | authoritative: 0/0 | | authoritative: 0/0 |
+---------------------+ +---------------------+ +---------------------+ +---------------------+
| \ / | | \ / |
| \ / | | \ / |
| / \ | | / \ |
| / \ | | / \ |
| | | | | | | |
V V V V V V V V
+--------------------------+ +--------------------------+ +--------------------------+ +--------------------------+
| DDT node1: 192.0.2.11 | | DDT node2: 192.0.2.12 | | DDT node1: 192.0.2.11 | | DDT node2: 192.0.2.12 |
| authoritative: 10.0.0.0/8| | authoritative: 10.0.0.0/8| | authoritative: 10.0.0.0/8| | authoritative: 10.0.0.0/8|
+--------------------------+ +--------------------------+ +--------------------------+ +--------------------------+
| \ / | | \ / |
| \ / | | \ / |
| / \ | | / \ |
| / \ | | / \ |
| | | | | | | |
V V V V V V V V
+--------------------------+ +---------------------------+ +--------------------------+ +---------------------------+
| Map-Server1: 192.0.2.101 | | DDT node3: 192.0.2.201 | | Map-Server1: 192.0.2.101 | | DDT node3: 192.0.2.201 |
|authoritative: 10.0.0.0/12| |authoritative: 10.16.0.0/12| |authoritative: 10.0.0.0/12| |authoritative: 10.16.0.0/12|
| site1: 10.1.0.0/16 | +---------------------------+ | site1: 10.1.0.0/16 | +---------------------------+
| site2: 10.2.0.0/16 | | | | site2: 10.2.0.0/16 | | |
+--------------------------+ | | +--------------------------+ | |
| | | |
| | | |
V V V V
+---------------------------+ +---------------------------+ +---------------------------+ +---------------------------+
| Map-Server2: 192.0.2.211 | | Map-Server3: 192.0.2.221 | | Map-Server2: 192.0.2.211 | | Map-Server3: 192.0.2.221 |
|authoritative: 10.16.0.0/16| |authoritative: 10.17.0.0/16| |authoritative: 10.16.0.0/16| |authoritative: 10.17.0.0/16|
| site3: 10.16.1.0/24 | | site5: 10.17.8.0/24 | | site3: 10.16.1.0/24 | | site5: 10.17.8.0/24 |
| site4: 10.16.2.0/24 | | site6: 10.17.9.0/24 | | site4: 10.16.2.0/24 | | site6: 10.17.9.0/24 |
+---------------------------+ +---------------------------+ +---------------------------+ +---------------------------+
DDT nodes are configured for this "root" at IP addresses 192.0.2.1 DDT nodes are configured for this "root" at IP addresses 192.0.2.1
and 192.0.2.2. DDT Map Resolvers are configured with default and 192.0.2.2. DDT Map Resolvers are configured with default
referral cache entries to these addresses. referral cache entries to these addresses.
The root DDT nodes delegate 10.0.0/8 to two DDT nodes with IP The root DDT nodes delegate 10.0.0/8 to two DDT nodes with IP
addresses 192.0.2.11 and 192.0.2.12. addresses 192.0.2.11 and 192.0.2.12.
The DDT nodes for 10.0.0.0/8 delegate 10.0.0.0/12 to a DDT Map Server The DDT nodes for 10.0.0.0/8 delegate 10.0.0.0/12 to a DDT Map Server
with RLOC 192.0.2.101 with RLOC 192.0.2.101
skipping to change at page 31, line 10 skipping to change at page 29, line 47
One-Time Key) from a Map-Resolver to the corresponding Map-Server. One-Time Key) from a Map-Resolver to the corresponding Map-Server.
For this reason, when LISP-SEC is deployed in conjunction with a For this reason, when LISP-SEC is deployed in conjunction with a
LISP-DDT mapping database and the path between Map-Resolver and Map- LISP-DDT mapping database and the path between Map-Resolver and Map-
Server needs to be protected, DDT security should be enabled as well. Server needs to be protected, DDT security should be enabled as well.
12. References 12. References
12.1. Normative References 12.1. Normative References
[LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format", draft-ietf-lisp-lcaf-02.txt (work in Address Format",
progress), March 2013. <http://www.ietf.org/id/draft-ietf-lisp-lcaf>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104, February Hashing for Message Authentication", RFC 2104, February
1997. 1997.
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, July 2006. (SHA and HMAC-SHA)", RFC 4634, July 2006.
skipping to change at page 31, line 37 skipping to change at page 30, line 26
Locator/ID Separation Protocol (LISP)", RFC 6830, January Locator/ID Separation Protocol (LISP)", RFC 6830, January
2013. 2013.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, January Protocol (LISP) Map-Server Interface", RFC 6833, January
2013. 2013.
12.2. Informative References 12.2. Informative References
[LISP-SEC] [LISP-SEC]
Maino, F., Ermagan, V., Cabellos, A., Sanchez, D., and O. Maino, F., Ermagan, V., Cabellos, A., and D. Sanchez,
Bonaventure, "LISP-Security", draft-ietf-lisp-sec-04.txt "LISP-Security",
(work in progress), October 2012. <http://www.ietf.org/id/draft-ietf-lisp-sec>.
[LISP-TREE]
Jakab, L., Cabellos, A., Coras, F., and D. Sauceez, "LISP-
TREE", 10 2010,
<http://dl.acm.org/citation.cfm?id=1878181>.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", BCP E. Lear, "Address Allocation for Private Internets", BCP
5, RFC 1918, February 1996. 5, RFC 1918, February 1996.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, February 2012. Secure Internet Routing", RFC 6480, February 2012.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol Alternative Logical
skipping to change at page 33, line 7 skipping to change at page 31, line 47
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ACT: The "action" field of the mapping record in a Map-Referral ACT: The "action" field of the mapping record in a Map-Referral
message encodes 6 action types. The values for the action types are: message encodes 6 action types. The values for the action types are:
NODE-REFERRAL (0): Sent by a DDT node with a child delegation which NODE-REFERRAL (0): Sent by a DDT node with a child delegation which
is authoritative for the EID. is authoritative for the EID.
MS-REFERRAL (1): Sent by a DDT node that has information about Map MS-REFERRAL (1): Sent by a DDT node that has information about Map
Server(s) for the EID but it is not one of the Map Servers listed, Server(s) for the EID but it is not one of the Map Servers listed,
i.e. the DDT-Node sending the referral is not a Map Server. i.e. the DDT-Node sending the referral is not a Map Server.
MS-ACK (2): Sent by a DDT Map Server that has one or more ETR MS-ACK (2): Sent by a DDT Map Server that has one or more ETR
registered for the EID. registered for the EID.
MS-NOT-REGISTERED (3): Sent by a DDT Map Server that is configured MS-NOT-REGISTERED (3): Sent by a DDT Map Server that is configured
for the EID-prefix but for which no ETRs are registered. for the EID-prefix but for which no ETRs are registered.
DELEGATION-HOLE (4): Sent by an intermediate DDT node with DELEGATION-HOLE (4): Sent by an intermediate DDT node with
authoritative configuration covering the requested EID but without authoritative configuration covering the requested EID but without
any child delegation for the EID. Also sent by a DDT Map Server any child delegation for the EID. Also sent by a DDT Map Server
with authoritative configuration covering the requested EID but with authoritative configuration covering the requested EID but
for which no specific site ETR is configured. for which no specific site ETR is configured.
NOT-AUTHORITATIVE (5): Sent by a DDT node that does not have NOT-AUTHORITATIVE (5): Sent by a DDT node that does not have
authoritative configuration for the requested EID. The EID-prefix authoritative configuration for the requested EID. The EID-prefix
returned MUST be the original requested EID and the TTL MUST be returned MUST be the original requested EID and the TTL MUST be
set to 0. However, if such a DDT node has a child delegation set to 0. However, if such a DDT node has a child delegation
covering the requested EID, it may choose to return NODE-REFERRAL covering the requested EID, it may choose to return NODE-REFERRAL
or MS-REFERRAL as appropriate. A DDT Map Server with site or MS-REFERRAL as appropriate. A DDT Map Server with site
information may choose to return of type MS-ACK or MS-NOT- information may choose to return of type MS-ACK or MS-NOT-
REGISTERED as appropriate. REGISTERED as appropriate.
Incomplete: The "I" bit indicates that a DDT node's referral-set of Incomplete: The "I" bit indicates that a DDT node's referral-set of
locators is incomplete and the receiver of this message should not locators is incomplete and the receiver of this message should not
skipping to change at page 36, line 39 skipping to change at page 35, line 12
indicate that the receiver can and should return Map-Referral indicate that the receiver can and should return Map-Referral
messages as appropriate. messages as appropriate.
Authors' Addresses Authors' Addresses
Vince Fuller Vince Fuller
Email: vaf@vaf.net Email: vaf@vaf.net
Darrel Lewis Darrel Lewis
cisco Systems Cisco Systems
Tasman Drive
San Jose, CA 95134
USA
Email: darlewis@cisco.com Email: darlewis@cisco.com
Vina Ermagan Vina Ermagan
cisco Systems Cisco Systems
Tasman Drive
San Jose, CA 95134
USA
Email: vermagan@cisco.com Email: vermagan@cisco.com
Amit Jain Amit Jain
Juniper Networks Juniper Networks
1133 Innovation Way
Sunnyvale, CA 94089
USA
Email: atjain@juniper.net Email: atjain@juniper.net
 End of changes. 51 change blocks. 
319 lines changed or deleted 315 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/