RE: [Rserpool] Last Call: draft-ietf-rserpool-overview (An Overview of Reliable Server Pooling Protocols) to Informational RFC
"Ong, Lyndon" <Lyong@Ciena.com> Tue, 15 April 2008 16:38 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E7528C428; Tue, 15 Apr 2008 09:38:54 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 222373A6BC1; Mon, 14 Apr 2008 12:53:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.547
X-Spam-Level:
X-Spam-Status: No, score=-1.547 tagged_above=-999 required=5 tests=[AWL=1.052, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tfBs58FDA9Er; Mon, 14 Apr 2008 12:53:32 -0700 (PDT)
Received: from hicks.ciena.com (hicks.ciena.com [63.118.34.22]) by core3.amsl.com (Postfix) with ESMTP id 75ED43A6C83; Mon, 14 Apr 2008 12:53:32 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Rserpool] Last Call: draft-ietf-rserpool-overview (An Overview of Reliable Server Pooling Protocols) to Informational RFC
Date: Mon, 14 Apr 2008 15:53:51 -0400
Message-ID: <23F9E58A916663488B3D12D1FE1A999F0125E929@mdmxm03.ciena.com>
In-Reply-To: <alpine.LRH.1.10.0804021713100.11246@netcore.fi>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Rserpool] Last Call: draft-ietf-rserpool-overview (An Overview of Reliable Server Pooling Protocols) to Informational RFC
thread-index: AciY1eazFtsePgaqQACZmZyRiGmMXgA7aT8g
References: <20080331131524.AF2BE3A6EA3@core3.amsl.com> <alpine.LRH.1.10.0804021713100.11246@netcore.fi>
From: "Ong, Lyndon" <Lyong@Ciena.com>
To: Pekka Savola <pekkas@netcore.fi>, ietf@ietf.org
X-OriginalArrivalTime: 14 Apr 2008 19:54:04.0911 (UTC) FILETIME=[4B1E97F0:01C89E69]
X-Mailman-Approved-At: Tue, 15 Apr 2008 09:38:53 -0700
Cc: rserpool@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
Hi Pekka, You have some very good comments. As you point out, the rserpool work is basically a research project at this point, with no known planned deployment over the Internet. We are targeting the protocol documents as Experimental in order to record the work. We will try to clarify the text in the areas that you found unclear, and document some of the issues that you identified as potential issues for configuration and administration. Cheers, Lyndon Ong -----Original Message----- From: rserpool-bounces@ietf.org [mailto:rserpool-bounces@ietf.org] On Behalf Of Pekka Savola Sent: Wednesday, April 02, 2008 7:20 AM To: ietf@ietf.org Cc: rserpool@ietf.org Subject: Re: [Rserpool] Last Call: draft-ietf-rserpool-overview (An Overview of Reliable Server Pooling Protocols) to Informational RFC On Mon, 31 Mar 2008, The IESG wrote: > - 'An Overview of Reliable Server Pooling Protocols ' > <draft-ietf-rserpool-overview-05.txt> as an Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the ietf@ietf.org mailing lists by 2008-04-14. Exceptionally, comments > may be sent to iesg@ietf.org instead. In either case, please retain > the beginning of the Subject line to allow automated sorting. Meta-level comment: ------------------- RSerPool architecture seems to require major changes pretty much everywhere where the architecture would be used: API changes in each application; ASAP client support in each host; ENRP home server support somewhere in the network; backup ENRP servers; ASAP client support in services: API changes in each server application; Multicast support between (PE) servers and ENRP servers; Multicast support between ENRP servers; multicast or static configuration in all client applications for ENRP server provisioning; possibly SCTP deployment between some of these (not clear from the document set); coordinating "pool handle" namespace unless that's equivalent to FQDN's. [I probably missed some required changes.] Yet, there exist similar mechanisms that do not require major client (or in some cases server) modifications (e.g. anycasting; load-balancing switches and DNS balancing; high availability services such as http://www.linux-ha.org). As a result, I would not expect this protocol to have practical deployment scenarios outside niche cases (e.g. some telco scenarios where SCTP is rumouredly used today). As a result I do not expect to see use or operational impact over the Internet. It seems like that there are about two implementations, both from the academia which seems consistent with the above reflection. Substantial: ------------ The draft mainly talks about ASAP and ENRP protocol overview from the ENRP server and PE perspective (sections 2 and 3). The text that is specific to the client perspective is somewhat scattered, and this issue is exacerbated by the fact that "client examples" in Section 4 (I looked at 4.1 only) lack specificity which would be essential to grasp how the material in sections 2 and 3 fit into the overall big picture when you consider it from the 'user' point of view. My suggestion is that the text in Section 4.1 should be clear enough so that anyone that has read the abbreviations (but not S 2 or S 3) should be able to understand how the big picture. 1. Instead of specifying the hostnames of primary, secondary, tertiary servers, etc., the application user specifies a pool handle. OK, you've here the pool handle. This is described a bit in ASAP and common-params drafts but both of these seem to lack the specifics. What you seem to be creating is a string that requires global coordination to be unique, otherwise there will be trouble where to look for the information. This resembles a hostname (and maybe it is meant to be FQDN in practise, "instead of invoking DNS translation again on the hostname ..." in step 3 later seems to imply so). Details are needed as how the pool handle namespace is expected to be managed and used. 2. Instead of using a DNS based service (e.g. the Unix library function getaddrinfo()) to translate from a hostname to an IP address, the application will invoke an RSerPool service primitive GETPRIMARYSERVER that takes as input a pool handle, and returns the IP address of the primary server. [...] Now you've described GETPRIMARYSERVER function (and later GETNEXTSERVER). These are not defined in this document, as as far as I can see, not in any currently available RSerPool WG document. How does the host know where to go (which IP address to contact, etc.) in order to perform this resolution? I.e., how do you discover RSerPool servers (ENRP server?) which respond to these mapping requests? If there are multiple RSerPool servers, which one(s) get selected and in which order? It might be that this is assumed to be "in the configuraton of the ASAP implementation on the client system", but if so, this ASAP client configuration "step zero" should also be described in the overview. How do you expect to provision the bootstrap configuration on ASAP client implementations? Some of this is described in Section 2.3 but describing the most important points, including how you know the home ENRP server, would be useful here. Similar issue exists in the description of server applications. The text should also address the transition aspects, i.e., what would be the good practise to provide both RSerPool and regular discovery (for cases where Rserpool isn't deployed) as well as both Rserpool and regular service creation. The text does not mention which protocol the PEs and PUs use to communicate with ENRP servers. I'd guess that in order to stay interoperable, at least some mandatory-to-implement mechanisms would need to be defined. Is it UDP, TCP, SCTP, or what ...? Does it work over NATs? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ rserpool mailing list rserpool@ietf.org https://www.ietf.org/mailman/listinfo/rserpool _______________________________________________ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Re: Last Call: draft-ietf-rserpool-overview (An O… Pekka Savola
- RE: [Rserpool] Last Call: draft-ietf-rserpool-ove… Ong, Lyndon