Re: server-to-server protocols

Mark Sirota <msirota@isc.upenn.edu> Wed, 16 April 1997 03:41 UTC

Received: from cnri by ietf.org id aa03348; 15 Apr 97 23:41 EDT
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa00912; 15 Apr 97 23:41 EDT
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA11874; Tue, 15 Apr 1997 23:36:36 -0400
Date: Tue, 15 Apr 1997 23:36:36 -0400
Message-Id: <33544246.77E1@isc.upenn.edu>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
Sender: dhcp-v4@bucknell.edu
Precedence: bulk
From: Mark Sirota <msirota@isc.upenn.edu>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: Re: server-to-server protocols
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0
X-Mailer: Mozilla 3.01 (Win95; I)

Kim Kinnear wrote:
> Anyway, the issue under discussion is: does the server-server protocol
> guarantee that the server that picks up for a failed server will
> extend leases just as the failed server would have, or does it extend
> leases "its own way".

Speaking as a provider of DHCP service rather than a designer, it seems
to me that nobody (clients or servers) should be making any assumptions
about exactly what binding information the server might hand out (based
on past observations, say) beyond those specified in the Draft Standard.
If true, this seems to be a very simple question.

I see three requirements:
(1) The client will accept whatever some server gives it, without
	making assumptions about server behavior.
(2) In a primary/backup multiple-server setup, the backup needs to be
	able to handle whatever the primary has given out, and the
	primary needs to be able to handle whatever the backup gave out
	while it was out to lunch.
(3) In a load-sharing peer multiple-server setup, each server needs to
	be able to handle whatever its peers give out.

So long as nobody makes any assumptions about server behavior beyond
those in the Draft Standard, why is this difficult?  Why complicate the
issue?

If people are providing multiple servers, why can't it be up to them to
ensure that they behave in a manner acceptable to them?  The clients
don't care.  The servers don't care.  If the users or the providers
care, well, then the providers already have a way to make this work --
use identical server software.

My vote is to keep it simple, and therefore to get it soon.

>         But my personal recommendation is that we build enough
>         configuration capability into the server-server protocol to
>         ensure that all of the servers in a group are configured with
>         the same addresses from the same subnets on the same wire --
>         and stop somewhere around there.

If we can get here easily, that's great, but this is far beyond my
opinion of the minimum.  The minimum is to ensure that if a server
becomes unavailable, another can take over for it without operator
intervention, without trampling on existing leases -- and that if the
server suddenly becomes available again, it won't trample on leases
that have been handed out in its absence.  The client software won't
care if the lease from one server is a little different from
another (and if the end user cares, it's up to the service provider to
ensure that it won't happen). Anything beyond that, from this particular
customer's point of view, is gravy.
-- 
Mark Sirota, Network Systems Engineer
University of Pennsylvania, Information Systems and Computing
msirota@isc.upenn.edu, 215/573-7214