Re: server-to-server protocols

[Erikas Aras Napjus <[e-mail]>]

> I especially would like Erikas to join the discussion, as his comments in 
> Memphis regarding the use of SNMP to read and set configuration data
> suggest another mechanism that might be useful (as an adjunct to the
> protocol which distributes binding data, for example).  Because of his
> interest in extending CMU's proposed DHCP MIB, I would hope Pratik might
> also participate.

Sean jumped in already, but I'll say a few more things:

SNMP might not be an unreasonable transport for whatever architecture we
choose for the server-to-server protocol. Assuming you make use of some
of SNMPv2 features, you have:

SNMPGET to pull direct information
SNMPGETBULK to pull lots of direct information (binding tables)
SNMPINFORM to push information out reliably (unlike traps)

As a transport, it's well tested with lots of reference implementations
for lots of different applications. And, as Sean pointed out, it
dovetails very well with our work on a DHCP MIB since the
server-to-server information is likely to be very similar to the sort of
client information we agreed should probably be available from the pure
SNMP MIB.

In fact, we might be interested in putting together a draft that
addresses the different architectural aspects that have already been put
forth with how they might be accomplished using SNMP as a transport. 

In terms of architecture (I haven't had enough time to read up on the
whole thread, so excuse any blatantly incorrect statements), we can look
at three types of information that could be passed between servers:

* 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).

* 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.

* 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.)


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.

Anyway, I've rambled enough about things that others have probably
already mentioned but haven't yet entered into my stream of
consciousness... :-)

--- Erikas