Re: server-to-server protocols

Kim Kinnear <> Wed, 16 April 1997 18:29 UTC

Received: from cnri by id aa13666; 16 Apr 97 14:29 EDT
Received: from by CNRI.Reston.VA.US id aa17747; 16 Apr 97 14:29 EDT
Received: from by; (5.65v3.2/ id AA16146; Wed, 16 Apr 1997 14:20:42 -0400
Date: Wed, 16 Apr 1997 14:20:42 -0400
Message-Id: <>
Precedence: bulk
From: Kim Kinnear <>
To: Multiple recipients of list <>
Subject: Re: server-to-server protocols
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4

Mark Sirota said:
> 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.

Kim responds:

	I think we agree (but let's delve into this a little deeper).

	I agree completely with your statement which starts "The
	minimum ...".  That's a wonderfully precise statement of the
	major goals of the server-server protocol.

	The *only* thing that I feel it necessary to add to the
	protocol vis a vis configuration information is just enough to
	ensure that the servers can detect obvious and potentially
	lethal administrator configuration errors.

	In a section of the mail that I removed above, you said
	something to the effect of: "If the admin cares to have the
	server handing out identical configuration info, then they
	should configure them that way".  I agree.  The problem I'm
	worried about is massive failure of the server-server
	protocol itself from mis-configuration.

	Let me give an example of the problem I'm trying to prevent:

	We have a secondary subnet situation (i.e. two subnets
	configured on the same "wire").  We have three servers -- two
	of them configured with the proper two subnets for that wire,
	and one of them configured with only one of the subnets.  They
	all have been configured to be in the same group of servers.
	If them simply join the group without some sort of check to see
	that they all really share a common subnet configuration,
	several bad things will happen.  First, the server with only a
	single subnet will NAK any clients of the other two servers
	when they INIT-REBOOT.  Second, if the server with the single
	subnet ends up on a partition with any of the clients of the
	other two servers, it will not allow them to extend their

	This second situation could occur if the servers simply had
	different IP addresses configured into each subnet.

	Either of these situations would compromise the operation of
	the server-server protocol directly.  That is why I believe
	that we should build enough -- just enough -- capability into
	the server-server protocol to prevent it from occurring.

	Cheers -- Kim