the future: failover (grim)

[David W. Hankins]

On Fri, Aug 11, 2006 at 09:47:11AM -0700, Ted Lemon wrote:
> It does save some bytes, but yeah, I didn't think it was that  
> useful.   But actually implementing the ability to receive batched  
> updates wasn't that hard, and it needs to be in there for  
> interoperability.   Nominum's DCS server does it, for example, so in  
> order for Nominum and ISC to interoperate I had to hack batched  
> updates into the ISC server.   The diffs for this were a bit to big  
> of a pill to swallow, though - I couldn't think of a way to package  
> them so that it would be easy for you to vet them.   :'(

I'm not going to be able to look at failover features again until
at least mid next year anyway.

I have to tell you, the lack of response I've received on the dhcwg
mailing list on the topic of the RECOVER-WAIT state protocol number
assignment has me rather wondering if the authors have no more
interest in this protocol anymore.  The lack of any dicussion about
the new angle on failover features (not even to skeptically say they
thought these methods were unwise) that I described from 3.1.0 has me
rather wondering if there's any interest in the protocol whatsoever
at IETF (except, it seems, to suggest total replacements).


I don't see any choice left to me now for 3.1.0 except to release
with the protocol number 254 for this state, which almost surely
isn't what other implementers have adopted (if they have even
adopted this protocol state).

Add to this that "DHCP Servers" still don't use a consistent, single
algorithm to identify clients, or at least a common language in which
both servers could be forced to agree, so that we will never have
two servers written by two people sitting next to each other quite
interoperating anyway (one will NAK clients asking for leases the
other is offering).

And interoperability is already shot in the foot.  A through-and-
through from the braincase, which as it turns out wasn't a vital
organ (at least, we haven't missed it all these years).


So.

IFF we get a draft revision 13, and what appears to be enough
momentum for this to go to the IESG someday.

IFF the workgroup is interested in completing the protocol's
evolution from the original simple stand-by system to today's
load-balanced architecture most folks implement.

IFF "the DHCP Protocol" consistently and without interpretation
identifies clients to leases, and any other not-failover-related
compatibility problems I'm forgetting...or at least that these
'interpretations' become strictly defined for failover operations.

Then I might consider taking on the (considerable - wether authoring
new code or reviewing submissions) work to support this feature,
rather than forking an alternative.

But right now failover as a protocol looks stillborn, and the features
now on head for 3.1.0 look very nearly like the last bit of blood I
can squeeze from this stone.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins