draft-ietf-lisp-ddt-06.txt   draft-ietf-lisp-ddt-07.txt 
Network Working Group V. Fuller Network Working Group V. Fuller
Internet-Draft Internet-Draft
Intended status: Experimental D. Lewis Intended status: Experimental D. Lewis
Expires: October 28, 2016 V. Ermagan Expires: December 2, 2016 V. Ermagan
Cisco Systems Cisco Systems
A. Jain A. Jain
Juniper Networks Juniper Networks
A. Smirnov A. Smirnov
Cisco Systems Cisco Systems
April 26, 2016 May 31, 2016
LISP Delegated Database Tree LISP Delegated Database Tree
draft-ietf-lisp-ddt-06 draft-ietf-lisp-ddt-07
Abstract Abstract
This draft describes the LISP Delegated Database Tree (LISP-DDT), a This document describes the LISP Delegated Database Tree (LISP-DDT),
hierarchical, distributed database which embodies the delegation of a 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
"child" DDT nodes to which more-specific EID-prefixes are delegated. "child" DDT nodes to which more-specific EID-prefixes are delegated.
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
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 October 28, 2016. This Internet-Draft will expire on December 2, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 2, line 32 skipping to change at page 2, line 32
4.2. Configuring prefix delegation . . . . . . . . . . . . . . 7 4.2. Configuring prefix delegation . . . . . . . . . . . . . . 7
4.2.1. The root DDT node . . . . . . . . . . . . . . . . . . 7 4.2.1. The root DDT node . . . . . . . . . . . . . . . . . . 7
5. DDT Map-Request . . . . . . . . . . . . . . . . . . . . . . . 8 5. DDT Map-Request . . . . . . . . . . . . . . . . . . . . . . . 8
6. The Map-Referral message . . . . . . . . . . . . . . . . . . 8 6. The Map-Referral message . . . . . . . . . . . . . . . . . . 8
6.1. Action codes . . . . . . . . . . . . . . . . . . . . . . 9 6.1. Action codes . . . . . . . . . . . . . . . . . . . . . . 9
6.2. Referral set . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Referral set . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Incomplete flag . . . . . . . . . . . . . . . . . . . . . 10 6.3. Incomplete flag . . . . . . . . . . . . . . . . . . . . . 10
6.4. Map-Referral Message Format . . . . . . . . . . . . . . . 10 6.4. Map-Referral Message Format . . . . . . . . . . . . . . . 10
6.4.1. SIG section . . . . . . . . . . . . . . . . . . . . . 12 6.4.1. SIG section . . . . . . . . . . . . . . . . . . . . . 12
7. DDT network elements and their operation . . . . . . . . . . 13 7. DDT network elements and their operation . . . . . . . . . . 13
7.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . 13 7.1. DDT node . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 13 7.1.1. Match of a delegated prefix (or sub-prefix) . . . . . 14
7.1.2. Missing delegation from an authoritative prefix . . . 14 7.1.2. Missing delegation from an authoritative prefix . . . 14
7.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . 14 7.2. DDT Map Server . . . . . . . . . . . . . . . . . . . . . 14
7.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . 14 7.3. DDT Map Resolver . . . . . . . . . . . . . . . . . . . . 15
7.3.1. Queuing and sending DDT Map-Requests . . . . . . . . 15 7.3.1. Queuing and sending DDT Map-Requests . . . . . . . . 15
7.3.2. Receiving and following referrals . . . . . . . . . . 15 7.3.2. Receiving and following referrals . . . . . . . . . . 16
7.3.3. Handling referral errors . . . . . . . . . . . . . . 17 7.3.3. Handling referral errors . . . . . . . . . . . . . . 17
7.3.4. Referral loop detection . . . . . . . . . . . . . . . 17 7.3.4. Referral loop detection . . . . . . . . . . . . . . . 18
8. Pseudo Code and Decision Tree diagrams . . . . . . . . . . . 18 8. Pseudo Code and Decision Tree diagrams . . . . . . . . . . . 18
8.1. Map Resolver processing of ITR Map-Request . . . . . . . 18 8.1. Map Resolver processing of ITR Map-Request . . . . . . . 19
8.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 18 8.1.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 19
8.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 19 8.1.2. Decision tree diagram . . . . . . . . . . . . . . . . 19
8.2. Map Resolver processing of Map-Referral message . . . . . 19 8.2. Map Resolver processing of Map-Referral message . . . . . 20
8.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 19 8.2.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 20
8.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 21 8.2.2. Decision tree diagram . . . . . . . . . . . . . . . . 22
8.3. DDT Node processing of DDT Map-Request message . . . . . 23 8.3. DDT Node processing of DDT Map-Request message . . . . . 24
8.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 23 8.3.1. Pseudo-code summary . . . . . . . . . . . . . . . . . 24
8.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 24 8.3.2. Decision tree diagram . . . . . . . . . . . . . . . . 25
9. Example topology and request/referral following . . . . . . . 24 9. Example topology and request/referral following . . . . . . . 25
9.1. Lookup of 2001:db8:0103:1::1/128 . . . . . . . . . . . . 26 9.1. Lookup of 2001:db8:0103:1::1/128 . . . . . . . . . . . . 27
9.2. Lookup of 2001:db8:0501:8:4::1/128 . . . . . . . . . . . 27 9.2. Lookup of 2001:db8:0501:8:4::1/128 . . . . . . . . . . . 28
9.3. Lookup of 2001:db8:0104:2::2/128 . . . . . . . . . . . . 28 9.3. Lookup of 2001:db8:0104:2::2/128 . . . . . . . . . . . . 29
9.4. Lookup of 2001:db8:0500:2:4::1/128 . . . . . . . . . . . 29 9.4. Lookup of 2001:db8:0500:2:4::1/128 . . . . . . . . . . . 30
9.5. Lookup of 2001:db8:0500::1/128 (non-existent EID) . . . . 29 9.5. Lookup of 2001:db8:0500::1/128 (non-existent EID) . . . . 30
10. Securing the database and message exchanges . . . . . . . . . 30 10. Securing the database and message exchanges . . . . . . . . . 31
10.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . 30 10.1. XEID-prefix Delegation . . . . . . . . . . . . . . . . . 31
10.2. DDT node operation . . . . . . . . . . . . . . . . . . . 31 10.2. DDT node operation . . . . . . . . . . . . . . . . . . . 32
10.2.1. DDT public key revocation . . . . . . . . . . . . . 31 10.2.1. DDT public key revocation . . . . . . . . . . . . . 32
10.3. Map Server operation . . . . . . . . . . . . . . . . . . 32 10.3. Map Server operation . . . . . . . . . . . . . . . . . . 33
10.4. Map Resolver operation . . . . . . . . . . . . . . . . . 32 10.4. Map Resolver operation . . . . . . . . . . . . . . . . . 33
11. Open Issues and Considerations . . . . . . . . . . . . . . . 33 11. Open Issues and Considerations . . . . . . . . . . . . . . . 34
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
13. Security Considerations . . . . . . . . . . . . . . . . . . . 33 13. Security Considerations . . . . . . . . . . . . . . . . . . . 34
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.1. Normative References . . . . . . . . . . . . . . . . . . 34 14.1. Normative References . . . . . . . . . . . . . . . . . . 35
14.2. Informative References . . . . . . . . . . . . . . . . . 34 14.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 35 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
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 Endpoint Identifiers (EIDs), used end-to-end for terminating
terminating transport-layer associations, and Routing Locators transport-layer associations, and Routing Locators (RLOCs), which are
(RLOCs), which are more dynamic, are bound to topological location, bound to topological location, and are used for routing and
and are used for routing and forwarding through the Internet forwarding through the Internet infrastructure.
infrastructure.
LISP offers a general-purpose mechanism for mapping between EIDs and LISP offers a general-purpose mechanism for mapping between EIDs and
RLOCs. In organizing a database of EID to RLOC mappings, this RLOCs. In organizing a database of EID to RLOC mappings, this
specification extends the definition of the EID numbering space by specification extends the definition of the EID numbering space by
logically prepending and appending several fields for purposes of logically prepending and appending several fields for purposes of
defining the database index key: Database-ID (DBID, 16 bits), defining the database index key: Database-ID (DBID, 16 bits),
Instance identifier (IID, 24-bits), Address Family Identifier (16 Instance identifier (IID, 32-bits), Address Family Identifier (16
bits), and EID-prefix (variable, according to AFI value). The bits), and EID-prefix (variable, according to AFI value). The
resulting concatenation of these fields is termed an "Extended EID resulting concatenation of these fields is termed an "Extended EID
prefix" or XEID-prefix. prefix" or XEID-prefix.
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
skipping to change at page 5, line 17 skipping to change at page 5, line 17
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), 24-bit IID and 16-bit AFI prepended. An XEID-prefix is used use), 32-bit IID and 16-bit AFI prepended. Encoding of the
as a key index into the database. prefix, its AFI and the instance ID (IID) are specified by
[I-D.ietf-lisp-lcaf]. An XEID-prefix is used 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.
skipping to change at page 7, line 11 skipping to change at page 7, line 11
Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map Server, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map Server,
and Map Resolver, please consult the LISP specification [RFC6830] and and Map Resolver, please consult the LISP specification [RFC6830] and
the LISP Mapping Service specification [RFC6833]. the LISP Mapping Service specification [RFC6833].
4. Database organization 4. Database organization
4.1. EID-prefix tree structure and instance IDs 4.1. EID-prefix tree structure and instance IDs
LISP-DDT defines a tree structure that is indexed by a binary LISP-DDT defines a tree structure that is indexed by a binary
encoding of five fields, in order of significance: DBID (16 bits), encoding of five fields, in order of significance: DBID (16 bits),
Instance Identifier (IID, 24 bits), Address Family Identifier (AFI, Instance Identifier (IID, 32 bits), Address Family Identifier (AFI,
16 bits), and EID-prefix (variable, according to AFI value). The 16 bits), and EID-prefix (variable, according to AFI value). The
fields are concatenated, with the most significant fields as listed fields are concatenated, with the most significant fields as listed
above. The index into this structure is also referred to as an above. The index into this structure is also referred to as an
Extended EID-prefix (XEID-prefix). Extended EID-prefix (XEID-prefix).
It is important to note that LISP-DDT does not store actual EID-to- It is important to note that LISP-DDT does not store actual EID-to-
RLOC mappings; it is, rather, a distributed index that can be used to RLOC mappings; it is, rather, a distributed index that can be used to
find the devices (Map Servers and their registered EIDs) that can be find the devices (Map Servers and their registered EIDs) that can be
queried with LISP to obtain those mappings. Changes to EID-to-RLOC queried with LISP to obtain those mappings. Changes to EID-to-RLOC
mappings are made on the ETRs which define them, not to any DDT node mappings are made on the ETRs which define them, not to any DDT node
skipping to change at page 8, line 36 skipping to change at page 8, line 36
IH | (uses RLOC or EID addresses) | IH | (uses RLOC or EID addresses) |
\ | | \ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = yyyy | / | Source Port = xxxx | Dest Port = yyyy |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LCM | LISP Control Message | LCM | LISP Control Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D-bit is the "DDT-originated" flag and is set by a DDT client to D: The "DDT-originated" flag. It is set by a DDT client to indicate
indicate that the receiver SHOULD return Map-Referral messages as that the receiver SHOULD return Map-Referral messages as
appropriate. Use of the flag is further described in Section 7.3.1. appropriate. Use of the flag is further described in
Section 7.3.1. This bit is allocated from LISP message header
bits marked as Reserved in [RFC6830].
6. The Map-Referral message 6. The Map-Referral message
This specification defines a new LISP message, the Map-Referral. It This specification defines a new LISP message, the Map-Referral. It
is sent by a DDT node to a DDT client in response to a DDT Map- is sent by a DDT node to a DDT client in response to a DDT Map-
Request message. See Section 6.4 for a detailed layout of the Map- Request message. See Section 6.4 for a detailed layout of the Map-
Referral message fields. Referral message fields.
The message consists of an action code along with delegation The message consists of an action code along with delegation
information about the XEID-prefix that matches the requested XEID. information about the XEID-prefix that matches the requested XEID.
skipping to change at page 10, line 46 skipping to change at page 10, line 46
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
| R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | R +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| e | Unused Flags |L|p|R| Loc/LCAF-AFI | | e | Unused Flags |L|p|R| Loc/LCAF-AFI |
| f +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator ... | | \| Locator ... |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ~ Sig section ~ | ~ Sig section ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: Map-Referral is LISP message type 6. Type: Type value 6 was reserved for future use in RFC6830, this
document allocates this value to identify Map-Referral messages.
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.
skipping to change at page 11, line 48 skipping to change at page 12, line 4
1 MS-REFERRAL NO YES 1440 1 MS-REFERRAL NO YES 1440
2 MS-ACK * * 1440 2 MS-ACK * * 1440
3 MS-NOT-REGISTERED * * 1 3 MS-NOT-REGISTERED * * 1
4 DELEGATION-HOLE NO NO 15 4 DELEGATION-HOLE NO NO 15
5 NOT-AUTHORITATIVE YES NO 0 5 NOT-AUTHORITATIVE YES NO 0
------------------------------------------------------------------- -------------------------------------------------------------------
*: The "Incomplete" flag setting on Map Server originated referral of *: The "Incomplete" flag setting on Map Server originated referral of
MS-REFERRAL and MS-NOT-REGISTERED types depend on whether the Map MS-REFERRAL and MS-NOT-REGISTERED types depend on whether the Map
Server has the full peer Map Server configuration for the same Server has the full peer Map Server configuration for the same
prefix and has encoded the information in the mapping record. prefix and has encoded the information in the mapping record.
Incomplete bit is not set when the Map Server has encoded the Incomplete bit is not set when the Map Server has encoded the
information, which means the referral-set includes all the RLOCs information, which means the referral-set includes all the RLOCs
of all Map Servers that serve the prefix. It is set when the Map of all Map Servers that serve the prefix. It is set when the Map
Server has not encoded the Map Server set information. Server has not encoded the Map Server set information.
SigCnt: Indicates the number of signatures (sig section) present in SigCnt: Indicates the number of signatures (sig section) present in
the Record. If SigCnt is larger than 0, the signature information the Record. If SigCnt is larger than 0, the signature information
captured in a sig section as described in Section 6.4.1 will be captured in a sig section as described in Section 6.4.1 will be
appended to the end of the record. The number of sig sections at the appended to the end of the record. The number of sig sections at the
end of the Record must match the SigCnt. end of the Record must match the SigCnt. Note that bits occupied by
SigCnt were Reserved in Records embedded into messages defined by
[RFC6830] and were required to be set to zero.
Loc/LCAF-AFI: If this is a Loc AFI, keys are not included in the Loc/LCAF-AFI: If this is a Loc AFI, keys are not included in the
record. If this is a LCAF AFI, the contents of the LCAF depend on record. If this is a LCAF AFI, the contents of the LCAF depend on
the Type field of the LCAF. Security material are stored in LCAF the Type field of the LCAF. Security material are stored in LCAF
Type 11. DDT nodes and Map Servers can use this LCAF Type to include Type 11. DDT nodes and Map Servers can use this LCAF Type to include
public keys associated with their Child DDT nodes for a XEID-prefix public keys associated with their Child DDT nodes for a XEID-prefix
referral record. LCAF types and formats are defined in referral record. LCAF types and formats are defined in
[I-D.ietf-lisp-lcaf]. [I-D.ietf-lisp-lcaf].
All other fields and their descriptions are equivalent to those in All other fields and their descriptions are equivalent to those in
skipping to change at page 35, line 27 skipping to change at page 36, line 27
[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
Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836,
January 2013, <http://www.rfc-editor.org/info/rfc6836>. January 2013, <http://www.rfc-editor.org/info/rfc6836>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The authors would like to express their thanks to Lorand Jakab, The authors would like to express their thanks to Lorand Jakab,
Albert Cabellos-Asparicio, Florin Coras, Damien Saucez, and Olivier Albert Cabellos-Asparicio, Florin Coras, Damien Saucez, and Olivier
Bonaventure for their work on LISP-TREE [LISP-TREE]and LISP iterable Bonaventure for their work on LISP-TREE [LISP-TREE] and LISP iterable
mappings that inspired the hierarchical database structure and lookup mappings that inspired the hierarchical database structure and lookup
iteration approach described in this document. Thanks also go to iteration approach described in this document. Thanks also go to
Dino Farinacci and Isidor Kouvelas for their implementation work; to Dino Farinacci and Isidor Kouvelas for their implementation work; to
Selina Heimlich and Srin Subramanian for testing; to Fabio Maino for Selina Heimlich and Srin Subramanian for testing; to Fabio Maino for
work on security processing; and to Job Snijders, Glen Wiley, Neel work on security processing; and to Job Snijders, Glen Wiley, Neel
Goyal, and Mike Gibbs for work on operational considerations and Goyal, and Mike Gibbs for work on operational considerations and
initial deployment of a prototype database infrastructure. Special initial deployment of a prototype database infrastructure. Special
thanks go to Jesper Skriver, Andrew Partan, and Noel Chiappa; all of thanks go to Jesper Skriver, Andrew Partan, and Noel Chiappa; all of
whom have participated in (and put up with) seemingly endless hours whom have participated in (and put up with) seemingly endless hours
of discussion of mapping database ideas, concepts, and issues. of discussion of mapping database ideas, concepts, and issues.
 End of changes. 21 change blocks. 
56 lines changed or deleted 60 lines changed or added

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