idnits 2.17.1 draft-wiley-lisp-ddtxfer-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 12, 2012) is 4420 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'LISP-MS' is defined on line 508, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-lisp-22 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-12 ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) == Outdated reference: A later version (-09) exists of draft-ietf-lisp-ddt-01 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Wiley, Ed. 3 Internet-Draft Verisign, Inc. 4 Intended status: Experimental March 12, 2012 5 Expires: September 13, 2012 7 LISP-DDT Database Transfer 8 draft-wiley-lisp-ddtxfer-01 10 Abstract 12 This draft describes a protocol for transferring a LISP Delegated 13 Database Tree (LISP-DDT) between DDT nodes and for notifying DDT 14 nodes that the database has changed. In the absence of a formally 15 defined protocol the LISP-DDT database is transferred using files 16 containing device configuration commands. This protocol provides for 17 transferring a complete database or the deltas between two versions 18 of the database. This document does not describe the use of DDT as 19 part of the LISP mapping service. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 13, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 1. Introduction 55 References to the LISP-DDT database in this document are intended to 56 refer specifically to the portion of the LISP-DDT database that has 57 been delegated to the DDT node, not the entire database. 59 An operator that offers a LISP-DDT service faces a few problems 60 (similar to those faces by the operator of a DNS resolution service): 62 o How to replicate the LISP-DDT database from one host/device to 63 another to support redundant platforms or to support operational 64 maintenance. 66 o Transfering the LISP-DDT between dissimilar platforms, for example 67 between network devices offered by competing network device 68 vendors that rely on different configuration commands. 70 o How to transfer portions of the LISP-DDT database rather than the 71 entire database (to deal with the eventual large database). 73 o How to notify an interested DDT node that the LISP-DDT database 74 has changed 76 The focus for this document is to define a protocol for the transfer 77 of the LISP-DDT database between DDT XFR nodes that addresses these 78 problems. The local representation of the data in the LISP-DDT 79 database on the DDT node is outside the scope of this document. 81 In the absence of a well described line protocol an operator might 82 send a list of OS commands to run on the DDT node that would populate 83 the LISP DDT database, however even this approach requires an 84 operational protocol to ensure a reliable/repeatable transfer of the 85 LISP DDT database. 87 There are two types of transfers, both are limited to only the 88 portion of the database that has been delegated to the DDT node. A 89 full transfer sends the entire set of entries in the database for 90 which the DDT node is authoritative. An incremental transfer sends 91 only the portion of that set of entries in the database that has 92 changed (based on the version of the database on the receiving node). 94 LISP-DDT bears some resemblance to the Domain Name Service (DNS) in 95 the sense that it provides an indirect vector to the target data. 97 Think of a LISP-DDT query as the analog to a DNS name server (NS) 98 query, and a LISP map request as the analog to a DNS address (A) 99 query (LISP-DDT does not store the EID to RLOC mappings returned in a 100 map request). 102 DDT XFR clients that need to be notified of changes to the DDT 103 database may subscribe to the appropriate DDT XFR server and are 104 asynchronously notified of changes. A DDT XFR client always 105 initiates a transfer by sending a request to the authoritative DDT 106 XFR server. 108 LISP-DDT database transfer introduces the use of a monotonically 109 increasing 64-bit serial number that identifies a version of a 110 portion of a LISP-DDT database. Each delegated portion of the 111 database (identified by a unique Extended EID-prefix) has a distinct 112 serial number which is maintained by the authoritative DDT XFR 113 server. One or more changes to the contents of the LISP-DDT database 114 increments the serial number. Once a serial number is used it may 115 never be reused. This feature ensures that a DDT XFR client can 116 reliably determine whether its copy of the LISP-DDT database is 117 consistent with the one offered by the DDT XFR server. This serial 118 number is analogous to the DNS SOA serial number. 120 1.1. LISP-DDT 122 LISP-DDT defines a database key for identifying EID mappings to RLOCs 123 in the EID numbering space. This key (the Extended EID prefix) is 124 comprised of the following fields: 126 +---------------------------------+-------------------------+ 127 | Field | Size | 128 +---------------------------------+-------------------------+ 129 | Key-ID | 16 bits | 130 | Instance Identifier (IID) | 32 bits | 131 | Address Family Identifier (AFI) | 16 bits | 132 | EID-prefix | variable length per AFI | 133 +---------------------------------+-------------------------+ 135 See [LISP-DDT] for a more complete discussion of the key fields. 137 The root DDT XFR server is the apex of the hierarchy and is 138 identified by the key: Key-ID=0, IID=0, AFI=0, EID-prefix=0/0 140 It is useful to note that a DDT node does not necessarily imply a 141 single host, in fact it is more likely implemented as a collection of 142 hosts operating behind a VIP or via some other mechanism that allows 143 for active redundant components. 145 1.2. Network Transport 147 TCP is used exclusively as the transport for LISP-DDT transfer 148 sessions as opposed to other LISP messages which are sent via UDP. 150 1.3. Terminology 152 Note that for the sake of consistency many of these definitions were 153 lifted directly from [LISP-DDT]. 155 Extended EID (XEID): a LISP EID, optionally extended with a non- 156 zero Instance ID (IID) if the EID is intended for use in a context 157 where it may not be a unique value, such as on a Virtual Private 158 Network where "private" address space is used. See "Using 159 Virtualization and Segmentation with LISP" in [LISP] for more 160 discussion of Instance IDs. 162 XEID-prefix: a LISP EID-prefix with 16-bit LISP-DDT Key-ID (provided 163 to allow the definition of multiple databases; currently always 164 zero in this version of DDT, with other values reserved for future 165 use), 32-bit IID and 16-bit AFI prepended. An XEID-prefix is used 166 as a key index into the database. 168 DDT node: a network infrastructure component responsible for 169 specific XEID-prefix and for delegation of more-specific sub- 170 prefixes to other DDT nodes. 172 Authoritative DDT node: The DDT map server that is authoritative for 173 a portion of the LISP-DDT database is identified as an 174 "authoritative DDT node/server" and is the exclusive source for an 175 authoritative copy of the portion of the LISP-DDT database that 176 has been delegated to that DDT map server. 178 DDT XFR client: The DDT node that is requesting a LISP-DDT database 179 transfer from a DDT XFER server. A DDT XFR client would likely be 180 a device/host that may serve as a DDT server following the 181 transfer. 183 DDT XFR server: The DDT node that receives a request for a LISP-DDT 184 database transfer and functions as the source of the LISP-DDT 185 database is the DDT XFR server. DDT XFR servers never initiate a 186 transfer, however they may send notification messages to DDT XFR 187 clients that have subscribed to the portion of the database for 188 which the DDT server is authoritative. 190 Full Transfer: A full LISP-DDT database transfer (FDDTXFR) describes 191 the transfer of the entire portion of the LISP-DDT database for 192 which a DDT-node is authoritative. The transfer does not include 193 portions of the database that are delegated to other DDT nodes. 195 Incremental Transfer: An incremental LISP-DDT database transfer 196 (IDDTXFR) is a transfer of the differences between two serial 197 numbers of the LISP-DDT database for which a DDT XFR server is 198 authoritative. The current serial number and the serial number 199 provided by the DDT XFR client determine the context of the 200 differences. 202 serial number: A monotonically increasing number that indicates a 203 specific version of the portion of the LISP-DDT database 204 identified by a unique Extended EID-prefix. There may be more 205 than one material difference between versions of the database even 206 though the serial number is incremented once. 208 session: A LISP-DDT database transfer session ("session") includes 209 all communication between the DDT XFR client and DDT XFR server 210 involved in requesting and responding to a request for the 211 transfer of a portion of the LISP-DDT database. 213 For definitions of other acronyms (EID, RLOC, etc.) see [LISP] and 214 [LISP-DDT]. 216 1.4. Requirements Language 218 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 219 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 220 document are to be interpreted as described in RFC 2119 [RFC2119]. 222 2. LISP-DDT Database Transfer Request 224 Immediately after the network connection is established from a DDT 225 XFR client to a DDT XFR server the DDT XFR client sends a transfer 226 request message. The LISP-DDT transfer message is very similar to 227 the LISP Map-Request. 229 0 1 2 3 230 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 |Type=9 |F|I|N| Reserved | EID mask-len | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | MAC Key ID | MAC Digest Length | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 ~ MAC Digest Data ~ 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Serial number . . . | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | . . . Serial number | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Key-ID | Instance Identifier ... | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | ... Instance Identifier | Address Family Id. | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | EID-prefix . . . | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | . . . EID-prefix | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 LISP-DDT Transfer Request Message Format 253 Packet field descriptions: 255 Type=9: DDT Transfer request, this four bit value identifies the 256 packet type (other LISP packet types are defined in the respective 257 Internet Drafts). 259 F (bit flag): If this bit is set then this is a full transfer 260 request. 262 I (bit flag): If this bit is set then this is an incremental 263 transfer request. 265 N (bit flag): If this bit is set then this is a notification that 266 the serial number for the portion of the database identified by 267 the Extended EID has changed. 269 EID mask-len: The EID mask length (in bits) of the EID-prefix, not 270 including the three fields that prefix the EID-prefix. 272 MAC Key ID: Identifies the Message Authentication Code (MAC) digest 273 algorithm per [LISP]. 275 MAC Digest length: Length in bytes of the following MAC digest data. 277 MAC Digest Data: The MAC digest data depends on the MAC Key ID 278 specified and is calculated on all of the fields that follow in 279 this message. 281 Serial number: In the case of an incremental transfer the DDT XFR 282 client populates this 64-bit value with the current serial number 283 so that the DDT XFR server can attempt to determine which database 284 changes must be sent. This field is ignored for full transfers. 286 Key-ID: 16 bit Key-ID for the X-EID prefix being requested. 288 Instance Identifier: 32 bit Instance Identifier for the X-EID prefix 289 being requested. 291 AFI: 16 bit Address Family Identifier for the X-EID prefix being 292 requested. 294 EID-prefix: The variable length EID-prefix (per AFI) for the XEID 295 prefix being requested. This length is also available in the 296 header of the packet. 298 3. Full LISP-DDT Database Transfer 300 A full LISP-DDT database transfer is initiated by a DDT XFR client as 301 a FDDTXFR request sent to a DDT XFR server. A DDT XFR server may 302 choose to ignore full transfer requests received from the same DDT 303 XFR client more than once in a 12 hour period. 305 This request is answered by successive DDTDAT messages until the 306 entire portion of the database is sent from the DDT XFR server. 308 4. Incremental LISP-DDT Database Transfer 310 An incremental LISP-DDT database transfer is initiated by a DDT XFR 311 client as a IDDTXFER request sent to a DDT XFR server. The DDT XFR 312 client specifies a serial number which is used by the DDT XFR server 313 to determine which changes must be sent in the reply. 315 The DDT XFR server should respond to the IDDTXFER request with an 316 IDDTXFER reply that includes only the changes between the specified 317 serial number and the current serial number. The DDT XFR server may 318 choose to respond with an FDDTXFER reply if the changes between the 319 serial numbers are no longer available to the DDT XFR server. 321 The DDT XFR client must be prepared to receive an FDDTXFER reply in 322 response to a IDDTXFER request. 324 5. LISP-DDT Transfer Data Message 326 0 1 2 3 327 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 |Type=11|F|I|H|N| Reserved | 330 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | | MAC Key ID | MAC Digest Length | 332 H +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 ~ MAC Digest Data ~ 334 b +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 i | Initial Serial number . . . | 336 t +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | | . . . Initial Serial number | 338 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | | Current Serial number . . . | 340 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | | . . . Current Serial number | 342 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | |A|R|L|Reserved | Record TTL . . . | 344 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 R |...Record TTL | Locator Count | EID mask-len | DB Key-ID... | 346 e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 c | ...DB Key-ID | Instance Identifier . . . | 348 o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 r |...Instance ID | EID-AFI | Reserved | 350 d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | | EID-prefix . . . | 352 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | /| Priority | Weight | M Priority | M Weight | 354 | L+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | o| Unused Flags |R| Loc-AFI | 356 | c+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | \| Locator ... | 358 +->+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 LISP-DDT Transfer Data Message Format 362 Packet field descriptions are identical to those for the LISP Map 363 Reply, new fields are described below: 365 Type=11: DDT Transfer Data Message, this four bit value identifies 366 the packet type (other LISP packet types are defined in the 367 respective Internet Drafts). 369 F (bit flag): If this bit is set then this is a response to a full 370 transfer request. 372 I (bit flag): If this bit is set then this is a response to an 373 incremental transfer request. 375 H (bit flag): If this bit is set then the data header is included in 376 the message. This header includes the message digest and serial 377 numbers of the versions of the database. The header typically is 378 included only in the first data message sent in response to a 379 request. 381 N (bit flag): NXDB, this bit is set in a response if the portion of 382 the database requested is not delegated to the DDT XFR server 383 responding to the request. If this bit is set then the Extended 384 EID-prefix is populated with the values specified in the original 385 request. 387 MAC Key ID: Identifies the Message Authentication Code (MAC) digest 388 algorithm per [LISP]. 390 MAC Digest length: Length in bytes of the following MAC digest data. 392 MAC Digest Data: The MAC digest data depends on the MAC Key ID 393 specified and is calculated on all of the fields that follow in 394 this message. 396 Initial Serial number: In an IDDTXFER reply, the initial serial 397 number is the serial number specified in the IDDTXFER request 398 provided that serial number was used to generate the changes 399 specified in the data messages. In a FDDTXFER request or in the 400 case that the DDT XFR server could not determine the changes 401 between the specified and current serial numbers then this field 402 is filled with 0's. If the H bit is not set then this serial 403 number is not present and the Extended EID prefix begins at this 404 location in the packet. 406 Current Serial number: In both the IDDTXFER and FDDTXFER reply, the 407 current serial number is provided in this field. If the H bit is 408 not set then this serial number is not present. 410 A (bit flag): For incremental transfers this bit is set to indicate 411 that the Extended EID prefix is to be added to the database. If 412 this bit is not set then the Extended EID prefix is to be removed 413 from the database. In cases where the Extended EID prefix is 414 duplicated by the add, the record is replaced in the database. 416 R (bit flag): For incremental transfers this bit is set to indicate 417 that the Extended EID prefix is to be removed from the database. 418 The A and R bits are mutually exclusive. 420 L (bit flag): This bit is set only in the last record of the DDTXFER 421 reply to indicate that no more records follow. 423 6. LISP-DDT Database Transfer Notify 425 A DDT XFR server maintains a list of DDT XFR clients that have 426 subscribed to the portion of the LISP-DDT database tree delegated to 427 that DDT XFR server. A DDT XFR client subscribes to a DDT XFR server 428 by communicating with the DDT XFR server operator who then configures 429 the DDT XFR server to send notifications. When the DDT XFR server 430 increments the serial number for the delegated portion of the 431 database, all DDT XFR clients are notified of the change via a 432 DDTNTFY message which is identical to a DDTXFER request message with 433 the N bit set. 435 Notifications are sent to DDT XFR clients within five minutes of the 436 change to the serial number. A DDT XFR server may choose to only 437 send the most recent/current serial number rather than all of the 438 serial numbers that were used between notifications to a DDT XFR 439 client. 441 Notifications are delivered via a reliable transport (TCP) and the 442 DDT XFR server must attempt to connect with the DDT XFR client and 443 send the notification at least three times within a three minute 444 window no more frequently than once per minute. The DDT XFR server 445 may choose a higher number of attempts at sending the notification, 446 but not more frequently than once per minute. 448 7. Acknowledgments 450 Special thanks to folks that offered their considerable experience in 451 building and operating large scale DNS platforms and helping 452 translate this experience to LISP-DDT database transfers including 453 Dave Blacka, Piet Barber and Sean Mountcastle. I also appreciate the 454 time that Neel Goyal and Ramin Ali Dousti have put into this effort. 456 8. IANA Considerations 458 This memo includes no request to IANA. 460 9. Security Considerations 462 There are a few Security considerations specific to LISP-DDT Database 463 Transfers that are incremental to the LISP-DDT specification. Most 464 of the security related requirements are satisfied by the use of TLS. 465 Although TLS as described in RFC 5246 [RFC5246] is intended to be 466 transparent to the application protocol, certain details should be 467 addressed to ensure consistent implementation of LISP-DDT Transfer. 468 These details are addressed in a separate document. 470 Two of the approaches to implementing security related features in 471 the protocol are to offer the secure service on an alternate port or 472 to allow session endpoints to upgrade an existing session via TLS. 474 The preferred approach to securing LISP-DDT Transfer is to offer the 475 secure service on an alternate port from the "un-secure" service. 476 The primary motivation for this approach is to improve operational 477 efficiency, for example this makes it easier to deploy a footprint 478 that efficiently allocates hardware used to accelerate TLS 479 termination. 481 An alternative to offering the secure service on an different network 482 port is to support session upgrades. In this case either endpoint of 483 a LISP-DDT transfer session may upgrade that session via TLS similar 484 to the approach taken to upgrade an HTTP session via TLS as described 485 in RFC 2817 [RFC2817]. 487 The use of TLS provides for the three primary security 488 considerations: 490 o Host authentication, both DDT XFR server and DDT XFR client can be 491 reasonably confident of the identity of the other endpoint. 493 o Transfer integrity, the contents of the transfer can be reasonably 494 assured to be unadulterated. The use of a message digest as is 495 currently specified for the protocol affords message integrity as 496 well. 498 o Transfer confidentiality, the contents of the transfer will be 499 essentially opaque to hosts outside the session. 501 10. References 502 10.1. Normative References 504 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 505 "Locator/ID Separation Protocol (LISP), 506 draft-ietf-lisp-22.txt", February 2012. 508 [LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server Interface, 509 draft-ietf-lisp-ms-12.txt (work in progress)", 510 October 2011. 512 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 513 Requirement Levels", BCP 14, RFC 2119, March 1997. 515 [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within 516 HTTP/1.1", RFC 2817, May 2000. 518 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 519 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 521 10.2. Informative References 523 [LISP-DDT] 524 Fuller, V., "LISP Delegated Database Tree, 525 draft-ietf-lisp-ddt-01.txt (work in progress)", 526 October 2011. 528 Appendix A. Open Issues 530 o A subscription message to manage DDT XFR client subscriptions to 531 DDT XFR servers for portions of the database would be very useful. 532 This requires a robust mechanism for authenticating subscribe/ 533 unsubscribe requests as part of the application protocol rather 534 than relying entirely on TLS. 536 o Compression should be included in the specification as an optional 537 feature. This will become more important as LISP is more widely 538 adopted and the size of the LISP-DDT increases. 540 o Do we need to support some sort of discovery protocol, for example 541 should a DDT XFR client be able to not specify some portion of the 542 extended EID prefix so that a DDT XFR server can reply with a 543 "default" database or offer some means to walk the portion of the 544 tree delegated to the DDT XFR server? 546 Author's Address 548 Glen Wiley (editor) 549 Verisign, Inc. 550 12061 Bluemont Way 551 Reston, Va 20190 552 USA 554 Phone: 555 Email: gwiley@verisign.com