1 / 7

IETF 59

IETF 59. Comparison of Protocols for Reliable Server Pooling <draft-ietf-rserpool-comp-07.txt> John Loughney. Protocols Covered. CORBA DNS Service Location Protocol (SLP) L4/L7 Switching. Issue 1.

mort
Télécharger la présentation

IETF 59

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. IETF 59 Comparison of Protocols for Reliable Server Pooling <draft-ietf-rserpool-comp-07.txt> John Loughney

  2. Protocols Covered • CORBA • DNS • Service Location Protocol (SLP) • L4/L7 Switching

  3. Issue 1 • The section on DNS will probably attract the most attention from the IESG. I think there are two issues with that section as it stands: first, it does not discuss DDDS (RFC3401 passim); second, it does not discuss EPP (draft-ietf-provreg-epp-09). Some sort of comparison with the qualities of those protocols is warranted, since they provide some qualities that, say, SRV does not. The potential use of URNs for pool handles should also be discussed along with DDDS. • Resolution: • Need for feedback from WG on how relevant DDDS and EPP is to RserPool.

  4. Issue 2 • In general, as well, the comparison to DNS seems a little questionable in so far as it assumes that there must be one protocol that performs the function of name resolution, keepalives, and NS provisioning. In fact, as I commented on the rserpool architecture document, those are separable functions with radically different properties and associated message exchanges, and very credible motivation is required to establish that a single protocol should be tooled to perform those functions. I think there are arguments to made against the use of the DNS for RSERPOOL, but I don't think it's fair to say that 'doesn't provide keepalives' is one of them. • Resolution: • Need to address this in the architecture & comment in this document.

  5. Issue 3 • In the SLP section (beginning of 2.3.3) in particular, the distinction between a service-oriented and communication-oriented solution is a little obscure to me. But overall I think the analysis here is sound. Same for the analyis of L4/L7 switching. • Resolution: • Tighten-up the text in this section.

  6. Dynamic Delegation Discovery System (DDDS) • The Dynamic Delegation Discovery System is used to implement lazy binding of strings to data, in order to support dynamically configured delegation systems. The DDDS functions by mapping some unique string to data stored within a DDDS Database by iteratively applying string transformation rules until a terminal condition is reached. This document defines the entire DDDS by listing the documents that make up the complete specification at this time.

  7. Extensible Provisioning Protocol • This document describes an application layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration.

More Related