ietf
[Top] [All Lists]

Re: Last Call: draft-ietf-rserpool-overview (An Overview of Reliable Server Pooling Protocols) to Informational RFC

2008-04-02 07:21:37
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(_at_)ietf(_dot_)org mailing lists by 2008-04-14. Exceptionally,
comments may be sent to iesg(_at_)ietf(_dot_)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
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>