Re: server-to-server protocols
Kim Kinnear <kinnear@american.com> Wed, 16 April 1997 18:27 UTC
Received: from cnri by ietf.org id aa13440; 16 Apr 97 14:27 EDT
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa17696; 16 Apr 97 14:26 EDT
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA09483; Wed, 16 Apr 1997 14:17:40 -0400
Date: Wed, 16 Apr 1997 14:17:40 -0400
Message-Id: <199704161715.NAA17974@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
Erikas said (concerning using SNMP as a transport for the server-server protocol): > > * Addresses available for leasing on any given subnet. This probably > needs some way of ensuring that addresses are handed out only by one > server at a time, but ideally could distribute the available addresses > amongst the servers automatically (or so I would think at least). In > theory, you could put a new server into an existing mix and it would > automatically pick up address space from the others if permitted. The > trick here is figuring out what to do about the address space when a > server is partitioned (intentionally or unintentionally) from the > network. If we don't do this, it simply degenerates into a case where > the address blocks are allocated manually on each server (losing load > balancing). Kim commented: Exactly. The ALT draft handles this partition case, and we plan to keep that approach in the combined 02 draft that Bob Cole, Ralph Droms, and I are working on. > * Dynamic client binding information. This goes back to the desire to > have redundency in leases between the servers so in the case of a failed > server or a network partition, clients can reestablish their existing > leases with a different server. Ideally, we want the basic information > propagated out (push) to all servers as quickly as possible (SNMPINFORM) > with the capability for a newly bootstrapped (hmmm) server to pull over > all the leases at once (SNMPGET / SNMPGETBULK). We probably don't want > to wait on a SNMPINFORM before responding to a request, so it makes more > sense to give someone an address, then update the servers. I'm far from expert on SNMP. I'll clearly be doing some more research soon, but let me ask you some (possibly stupid) questions: 1. Using SNMPINFORM can one send information about multiple happenings in one message? 2. You mention that SNMPINFORM is reliable. Is that more than simply a request->response pair? > * Static client binding information. This is just a subset of the > dynamic case, although there might be a slightly different application. > In theory, you could have a machine which "seeds" your server farm with > static address allocations like a bootptab file might do on a server > today. In our environment (semi-isolated case), we could have our > database directly talk the server-to-server protocol to distribute > static bindings and dynamic address allocations, but not have it be a > DHCP server at all. (We currently us AFS to copy files between the > database machine and our server machines which, frankly, isn't the > greatest solution.) Certainly having non-serving members of a DHCP server-server protocol group is a neat idea that is currently also in the ALT draft and that I think we'll keep (since we'd have to try hard to prevent it, and that would be foolish). > As I mentioned in the working group, we currently have a network > monitoring system based upon SNMPINFORMs as a transport. The different > "modules" of the system communicate with each other via SNMPINFORMs, > thereby passing network event information around. It works pretty well > and is pretty stable. It's fairly simple to extend the basic model to a > DHCP environment instead. Do you have *any* information as to the performance, actual or potential, of this approach? One of my concerns about SNMP is that its complexity may limit the ultimate performance of the protocol and thereby create a server-server protocol that doesn't scale well. While we haven't set firm goals yet, I believe that we need to be able to support DHCP servers with >100K IP addresses (probably *much* greater than 100K). We need a protocol architecture that will support servers that are required themselves to handle at *least* 50 and more likely 100-200 transactions/sec. But this is another good topic for the list, I guess. (To be clear, I'm not saying we can do 200 transactions/second today, but that I don't want the server-server protocol to be the reason that we can't get there tomorrow!) > Anyway, I've rambled enough about things that others have probably > already mentioned but haven't yet entered into my stream of > consciousness... :-) Thanks for raising the issue -- better we figure it out now than later -- after we've already done all of the work going in another direction. 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