Re: server-to-server protocols

[Kim Kinnear <[e-mail]>]

Barr,

You've raised a really good point!  Thanks.

Before we get into the meat of the issue, does anyone think we should
move this to the server-server mailing list?

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

Bob Cole said:

> >I guess I naively assumed both. That is, 1) I started to build an 
> interserver
> >message that included the full client binding information and
> >2) I simply assumed that a goal of the interserver protocol
> >was to allow the configuration of a single server of the SG and
> >have this propagate throughout the SG.  But you raise a good point
> >that I hadn't considered, i.e., that these are seperable.

Barr replied:

> It is probably a much simpler approach to have a server report the binding 
> to other servers in the group than to synchronize the data from which the 
> binding is constructed.  The former seems to me to be one of the fundamental 
> requirements of a server-to-server protocol, while the latter seems to me to 
> be the beginnings of a specification on the internal design of a server.

Kim adds:

	I tend to agree, although I would see the later less as a
	specification of the internal design of a server, and more as a
	server configuration protocol.  Granted that a server
	configuration protocol would tend to determine the architecture
	and features of a server in some significant ways -- so we are
	agreeing in the end.

	There certainly are two "models" of inter-server protocol, and
	we'll shortly have to decide between them.

	It might be worth my adding some distinctions that we've made
	in the DHCP configuration information in our server, and that
	in one way or another I suspect other implementors have made as
	well.  We have three classes of DHCP configuration
	information:

    Address-Oriented:

	Information about the network topology, addresses that can be
	allocated, reservations, DNS update reverse zone info,
	information on multiple subnets/wire (i.e., secondary subnet),
	BOOTP and dynamic BOOTP information, etc.  This is the
	"physical" information necessary to perform the basic DHCP
	protocol and contains information that is associated with an IP
	address, in as much as a different pool of addresses might need
	or want to have different values for these configuration
	parameters.

    Option-Oriented:

	Lease time, grace period, options that can be returned to the
	client, BOOTP file and server information.  Lots of volume
	here.

    Client-Oriented:

	Infomation about which clients to allow and disallow, which
	type of IP address to offer to them, user-class definitions and
	mappings from client to user-class for those cases where people
	want them hard-coded, specific host name mappings, etc.  These
	are for people who want to register some or all of their
	clients specifically in their DHCP server and/or support the
	user-class concept.

    ------------

	As it turns out, the option-oriented configuration information
	is contained in something we call a "policy".  The address
	oriented information points to a policy, and both the client
	and user-class also can point to a policy, with the most
	specific overriding the less specific on an option by option
	basis.  Whew!

	I made this rather long explanation for two reasons:

	1. To give us some names to use for different types of
	configuration information.

	2. To make the point that no matter *what* we do, I don't think
	we're going to be able to invent a server-server configuration
	protocol that would enable our server to get its *complete*
	configuration from another server written by someone else.  Not
	without a *lot* of "vendor specific" escapes -- and having too
	many rapidly degrades any value in doing this at all.

	-----------

	That said, I have been hoping (and planning) to put enough in
	the server-server protocol so that most of the standard
	address-oriented configuration information could be transferred
	between servers when they join a group.  This could be used to
	check to see that the internal configuration of the server
	matched that of the rest of the group (because if it didn't,
	some *very* strange things could happen).  It could also be
	used to configure the address portion of the server directly
	(in which case it would certainly match the other servers).

	I was thinking that we would avoid tackling the option-oriented
	or client-oriented configuration information this pass in the
	server-server protocol, though if enough of you out there want
	us to, we could give it a try.

	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.

Barr continues:

> Here I'm looking for guidance.  I think that if a different server offers to 
> rebind the client, it is entirely reasonable to assume that the offer may be 
> slightly different, simply because the original and rebinding servers may, 
> of practical necessity, have slightly different sets of default data and 
> server-specific configuration.  And so, while we wouldn't guarantee an 
> identical binding to a client, we would be proposing a highly similar one. 
>  I think that this may not only be a reasonable approach, it may be the only 
> one that will interoperate.

	Kim agrees!
> 
> Comments, criticisms, and suggestions are welcomed at this point -- just 
> what does the mailing list think?  An implication of the "simple binding 
> data" approach is that the client may not get an identical lease when 
> rebinding.  But is that really any different from the case where the 
> original server has some option default changed which would apply to the 
> client during rebinding?

Kim says:

	I think that this would be OK for a first pass at the
	server-server protocol.  Doing much more could push the
	time to specify (let alone the time to implement) out
	quite a bit.