Subject: [Rserpool] Comments on the Architecture document

From: [email-masked]
Date: Mon, 27 May 2002 13:53:35 -0500

Michael,

Some initial comments:

Author list:

Lyndon is now at Ciena, not Point Reyes Networks.

1.1.  Overview

For accessing a server pool a flat system of name servers can be used.

*** The name space is flat, not the name servers.  Also mention the fault
tolerant aspects of the name servers.  Something like:

To access a server pool, the pool user consults a name server.  The name
space for the server pools is flat, rather than hierarchical.  A group of fault tolerant name servers are provided to resolve pool name queries from the PU.

Name server:
          Entity which the responsible for managing and maintaining the
          name space within the RSerPool operation scope.
Should be:
Name server:
          Entity which is responsible for managing and maintaining the
          name space within the RSerPool operation scope.

2.  Reliable Server Pooling Architecture

In this section, we discuss what a typical reliable server pool
architecture may look like.

*** Too vague.  An architecture can be defined.  An implementation of that
architecture  (such as how many servers in the pool, etc.) can be variable.
How about:

In this section, we define a reliable server pool architecture.

2.1.  RSerPool Functional Components

The second class of entities in the RSerPool architecture is the class
of the so called name servers.

*** Name server is a common term.  Don't need the "so called".  How about:

The second class of entities in the RSerPool architecture is the class
of the name servers.

These name servers can resolve a pool
handle to a list of information which allows the PU to access a PE of
the server pool identified by the handle. This information includes:

     -    A protocol field of the IP header specifying the upper layer
          protocol.

     -    A port number if the upper layer protocol is SCTP, TCP or UDP.

*** Did you forget the IP address(es)?  You should also mention support for
IPv4 AND IPv6.  They can't get to the PE with just the port number and the protocol field.  You might want to proceed this with something like:

The second class of entities in the RSerPool architecture is the class
of name servers.  Name servers resolve pool handle names on behalf of the
PU.

The Rserpool architecture supports both IPv4 and IPv6 addressing for the PE.
Furthermore, the PE must specify which transport(s) it supports.  Multiple transports are allowed (is this right?)  This allows the PU to determine unambiguously how it can communicate with a PE.

These name servers can resolve a pool handle to a list of PEs which allows the PU to access a PE of the server pool identified by the handle. For each PE in the list, this information includes:

     -    A protocol field of the IP header specifying the upper layer
          protocol.

     - A transport address which includes a port number and an IPv4 or IPv6
address if the upper layer protocol is SCTP, TCP or UDP.

*** Small Note that your definitions in the architecture doc and the ASAP
doc should be the same.  In ENRP, it refers to the architecture doc for any overlapping definitions.  Maybe ASAP should
do the same.  However, when I read a document, it is annoying not to have
important terms defined.  These definitions are all critical to the text.  We can talk about this at the interim meeting.  All terms should be defined in this architecture document -- it is just too important to refer to somewhere else.  Maybe ASAP could refer to your doc for now and then replicate the definitions just before last call.  I think someone said this on the list.

-- maureen

_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool