Re: server-to-server protocols
Kim Kinnear <kinnear@american.com> Wed, 16 April 1997 18:29 UTC
Received: from cnri by ietf.org id aa13666; 16 Apr 97 14:29 EDT
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa17747; 16 Apr 97 14:29 EDT
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA16146; Wed, 16 Apr 1997 14:20:42 -0400
Date: Wed, 16 Apr 1997 14:20:42 -0400
Message-Id: <199704161647.MAA17783@hotsprings.american.com>
Errors-To: droms@bucknell.edu
Reply-To: dhcp-v4@bucknell.edu
Originator: dhcp-v4@bucknell.edu
Sender: dhcp-v4@bucknell.edu
Precedence: bulk
From: Kim Kinnear <kinnear@american.com>
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
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 leases. 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
- server-to-server protocols Hibbs, R Barr (rbhibbs)
- Re: server-to-server protocols Ted Lemon
- Re: server-to-server protocols Hibbs, R Barr (rbhibbs)
- Re: server-to-server protocols Ted Lemon
- Re: server-to-server protocols Robert G. Cole
- Re: server-to-server protocols Hibbs, R Barr (rbhibbs)
- Re: server-to-server protocols Kim Kinnear
- Re: server-to-server protocols Ted Lemon
- Re: server-to-server protocols Hibbs, R Barr (rbhibbs)
- Re: server-to-server protocols Sean Goller
- Re: server-to-server protocols Ted Lemon
- Re: server-to-server protocols Ted Lemon
- Re: server-to-server protocols Erikas Aras Napjus
- Re: server-to-server protocols Erikas Aras Napjus
- Re: server-to-server protocols Mark Sirota
- Re: server-to-server protocols Ted Lemon
- Re: server-to-server protocols Kim Kinnear
- Re: server-to-server protocols Kim Kinnear