Subject: [Rserpool] Re: draft-ietf-rserpool-comp-00.txt

From: Erik Guttman <[email-masked]>
Date: Fri, 13 Jul 2001 16:33:47 +0200 (MET DST)

Folks,

I sent this message previously to the authors of the comparison
document, but I haven't gotten any response.  For the record and
to stimulate discussion, I am sending it to the mailing list.

This mail contains comments on draft-ietf-rserpool-comp-00.txt WRT SLP.
These comments are meant to address technical inaccuracies in the
document not to imply that SLP fulfills *all* rserpool 
requirements.    But SLP is adequate to fulfill many of them.

I suggest a more thorough assessment of SLP against the requirements 
is needed.  I would be willing to participate in preparing this 
assessment.

2.3 Service Location Protocol

   SLP is comprised of three components: User agent, service agents and
   directory agents. User agents work on the user's behalf to contact a
   service. The UA retrieves service information from service agents or
   directory agents. A service agent works on behalf of one or more
   services to advertise services. A directory agent collects service
   advertisements.

   The directory agent of SLP functions simply as a cache and is
   passive in this regard. Also, the directory agent is optional and
   SLP can function without it. It is incumbent upon the servers to
   update the cache as necessary by reregistering. The directory server
   is not required in small networks as the user agents can contact
   service agents directly using multicast. 

It is also possible to unicast queries to SAs - for instance - subsequent
to having discovered them initially via multicast service discovery
or via SA discovery, etc.

   User agents are encouraged
   to locate a directory at regular intervals if they can't find one
   initially.

UAs can also detect DAs by listening passively for DA advertisements.
   The most fundamental difference between SLP and RSerPool is that SLP
   is service-oriented while RSerPool is communication-oriented. More
   specifically, what SLP provides to its user is a mapping function
   from a name of a service to the location of the service provider, in
   the form of a URL string. Whether the service provider is reachable
   and how to access it by the URL are out of the scope of SLP.
   Therefore, the granularity of SLP operation is at application
   service level.

The manner in which one access the service can be described using
the attribute list associated with the service URL.

   In contrast, what RSerPool provides to its user is a mapping
   function from a communication destination name to a set of routable
   and reachable transport addresses that leads to a group of
   distributed software server entities registered under that name that
   collectively represent the named communication destination.

This information could also be represented in SLP attributes.

   RSerPool
   also takes the responsibility of reliably delivering a user message
   to one of these server entities. What service(s) this group of
   servers are providing at the application level or whether the group
   is just a component of an application service provider is out of the
   scope of RSerPool. In other words, the granularity of RSerPool
   operation is at communication server entity level.

Agreed.  SLP is a discovery protocol, not a transport protocol.
Still, these are distinct functions.  One could use SLP to 
discover which (suitable) servers exist and also which to use
(based on load information, etc.)  The transport function of
rserpool could use this information to provide its services.

   Moreover, RSerPool is designed to be a distributed fault-tolerant
   and real time translation service. SLP does not state either of
   these as design requirements and thus does not attempt to fulfill
   them. 

   In addition, SLP defines optional security features which
   support authentication and integrity.

If a SLP UA issues a request specifying security parameters,
only SAs and DAs will respond which can supply appropriately
secured replies.  In this sense security is not optional in
SLP.

   These are mandatory to
   implement but optional in terms of use. RSerPool has stronger
   security requirements.

Does it?  draft-ietf-rserpool-reqts-03.txt states the security
requirements to be:

  2.13.1.  General

YES    -    The scaling characteristics of the security architecture
            should be compatible with those given previously.

YES    -    The security architecture should support hosts having a wide
            range of processing powers.

  2.13.2.  Name Space Services

YES    -    It must not be possible for an attacker to falsely register as
            a pool element with the name server either by masquerading as
            another pool element or by registering in violation of local
            authorization policy.

YES    -    It must not be possible for an attacker to deregister a server
            which has successfully registered with the name server.

YES    -    It must not be possible for an attacker to spoof the response
            to a query to the name server

YES    -    It must be possible to protect the privacy of queries to the
(with       name server and responses to those queries from the name
IPSec)      server.

YES       - Communication among name servers must be afforded the same
(may        protections as communication between clients and name servers.
require
IPSec)

   The SLP directory agent does not support fault tolerance or
   robustness in contrast to the name servers which do support it.  

By fault tolerance, I assume you mean the following requirements
from draft-ietf-rserpool-reqts-03.txt

  2.1.  Robustness
 
  The solution must allow itself to be implemented and deployed in such a
  way that there is no single point of failure in the system.

  2.2.  Failover Support

  The RSerPool architecture must be able to detect failure of pool
  elements and name servers supporting the pool, and support failover to
  available alternate resources.

SLP does support this.  See RFC 3049 - a standards track protocol which
supports exactly this function for a specific application.

   The
   name servers also monitor the state of the servers which are
   registered in the pool but the SLP directory agents do not perform
   this function. 

Very short registration lifetimes in SLP can achieve the same, unless
one is looking for sub-second accuracy.  SLP would require a lot of
updates in this case, but this would be true of any centralized solution
for naming with a high degree of correspondence between the name &
the actual state of the name binding.

Another possibility would be to use naming to locate rserpool endpoints
and then use the 'transport' protocol to provide monitoring functions.

   SLP uses multicast and in RSerPool multicast is
   optional.

In SLP multicast is also optional.  If DHC configuration is done,
all agents may be configured with a set of DA addresses.  All 
SLP communication in this case proceeds via unicast.  

Erik

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

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 16 Jul 2001 17:43:42 -0500

Erik Guttman wrote:
...snip....
> supports exactly this function for a specific application.

Erik,

I am a little puzzled by this statement. The only time RFC 3049 mentions
about failure handling seems to be in 5.4. Let me quote it here:

======
5.4 Recommendations

...
   In the event that after the TN3270E client has determined the least
   loaded server and the connection to that server fails for some
   reason, the connection should be closed and an attempt made to
   connect to other TN3270E servers in the list of least loaded servers.
======

It is not clear to me at all that who is going to detect the failure of
the first connection and who is going to perform the re-connect. Nor
does it say anything about how the connection failure is detected.

Fast-detection of failure (in a few seconds or less) and transparent
failover to an alternative server (i.e., no need for upper layer
assistance) ARE the key design objectives for RSERPOOL. I don't see any
of these is addressed in RFC 3049 at all.

Moreover, RSERPOOL fault-tolerant is aimed at real-time (or
semi-real-time) environments such as telephony call control environment,
while RFC 3049 is designed exclusively for telnet over TCP sessions.

Am I missing something?

-Qiaobing