Subject: RE: [dhcwg] Failover: poolreq message secondary-only?

From: Kim Kinnear <[email-masked]>
Date: Mon, 05 Nov 2001 10:39:14 -0500

At 07:02 PM 11/2/2001 -0600, Bernie Volz (EUD) wrote:

>The primary can also simply initiate a reclaim of addresses by sending requests to the secondary. 
>
>We originally set up the PoolReq the way it is documented before load balancing really seriously entered the picture. But, we did discuss this several times after load balancing was introduced and felt it wasn't necessary since the flow of addresses was typically back to the primary and since it "owned" these, it was more in control of what it gave to the secondary.

        I agree.  I even went back into my minutes from the
        various failover conference calls to verify this, and
        determined that we *did* agree with precisely what Bernie
        said.

        I actually advocated (at one point) allowing a
        bi-directional POOLREQ mechanism, but generally the
        feeling (and not just from Bernie, though he was an
        advocate for this position) was that having the primary
        make the global decisions via the POOLREQ was a good
        thing.

        During the discussions we generally were moving toward a
        model of either server using BNDUPD to move addresses
        around as needed on a more steady-state model.  Of course
        the POOLREQ uses BNDUPD's to move addresses too.  This
        requires more code (or more distributed code), but keeps
        the balance much better as well as distributing over time
        the load of checking everything out -- where a POOLREQ
        requires a global check of everything all at one time.

        I intended to add considerable text through the draft to
        discuss the implications of this approach.  It is
        possible that I didn't add enough (or do it clearly
        enough).

        Ultimately, the issue here is whether you believe in the
        use of BNDUPD to move addresses as necessary -- and
        initiated by either server, or whether you believe that
        POOLREQ (using, of course, BNDUPD as well) is always the
        way to do it.

        The strategy embodied in the current draft is to have the
        secondary issue a POOLREQ to get the primary to do the
        bulk balancing, and then to use BNDUPD to do the detailed
        balancing.  The primary would also then use BNDUPD to do
        the detailed balancing.  Or that was the intent of what I
        wrote when I updated the draft.

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

        One way to get what you want (without changing the draft
        at all, which at this stage I see as a plus), would be
        for your implementation of POOLREQ on the primary to
        include not just a "push" of addresses to the secondary
        but also to embody a "pull" of addresses from the
        secondary to establish the "best" balance possible.
        Then, the primary could process a POOLREQ from the
        secondary, but it could also initiate a "POOLREQ"-type of
        processing even though it didn't actually receive a
        POOLREQ message from the secondary (similar to the way
        BNDUPDREQ are handled -- sometimes they are requested,
        sometimes you do them "on-your-own").  Whenever the
        primary did the POOLREQ processing it would balance the
        pools using BNDUPD in either direction, and not simply
        push out addresses to the secondary.

        The advantage of this approach would be that the primary
        and secondary would never argue about the balance (where
        an argument would look like a constant flow of addresses
        from one to the other and then back again).

        I would be glad to enhance the draft with words that
        would make clear the possibility of this approach (which
        would not change the protocol, but rather enhance the
        understanding of the protocol) as a result of IESG last
        call (which will be ... whenever it happens).

        I'm concerned about making even as apparently simple a
        change as allowing a POOLREQ from either server because
        of the other (apparently related) questions which it may
        open up (as you have already noticed).  I sent out about
        5 pages of email discussion (edited to make it short and
        concise) and we spent about 45 minutes in a conference
        call about one year ago discussing some of these loosely
        related issues.  We reached a consensus but not absolute
        agreement -- and the discussion could clearly go on again
        for a longer period of time and reach no better closure.

        I do not believe what we currently have in the draft is
        perfect, but I believe that it is more than good enough
        to allow us to build something that works and works well.
        It is clearly the work of a group of people.  As such it
        has the benefit of being more fully thought through, and
        also bears the stigma of being less globally consistent
        and clean than would the work one or two people working
        closely together.

        At this stage I am interested in finding ways to push it
        to RFC status in order to "rachet" the good work that we
        have all put into this endeavor -- and keep it from being
        another draft that goes on forever and is wrangled about
        forever and never really amounts to anything.

        That said, if this is a big deal for you and you believe
        it is worth the risk of revisiting all of these questions
        again (which I clearly do not want to do), we can revisit
        this question of "who can do a POOLREQ" as a result of
        IESG last call.

        Cheers -- Kim

>Either server can request state changes to move an address to itself. 
>
>Note sure if this explains it well enough. But, I don't see a real need for doing this. Ted, perhaps you have a specific case for why this might be needed? It would be interesting to hear of it.
>
>- Bernie 
>
>-----Original Message----- 
>From: steve [<mailto:[email-masked]>mailto:[email-masked]] 
>Sent: Friday, November 02, 2001 6:23 PM 
>To: 'Ted Lemon' 
>Cc: [email-masked] 
>Subject: RE: [dhcwg] Failover: poolreq message secondary-only? 
>
>Given what we have, leases flow to the primary, as they get assigned. 
>
>What you propose would allow the primary to reclaim some of the un-used 
>backup 
>pool during normal operation. 
>
>I believe the current protocol already allows for this during 
>synchronization. 
>After the primary received all updates from the secondary, it can safely set 
>the status of any "backup" lease to "free", because the backup is not 
>running 
>until the synchronization is complete. 
>
>All said, what you propose is useful and worth doing. 
>
>/sg 
>
>-----Original Message----- 
>From: Ted Lemon [<mailto:[email-masked]>mailto:[email-masked]] 
>Sent: Friday, November 02, 2001 5:32 PM 
>To: [email-masked] 
>Cc: [email-masked] 
>Subject: Re: [dhcwg] Failover: poolreq message secondary-only? 
>
>> Leases should belong to either the primary or the backup, 
>> regardless of their status ( free, active, abandoned...). 
>> 
>> This would be conceptually much cleaner. 
>
>Good heavens, that wasn't what I was proposing at all.   That would require 
>a complete rewrite of the spec, which is out of the question.   I'm just 
>asking for the restriction that only the secondary can send poolreq, and 
>the primary send poolresp, be removed. 
>
>
>_______________________________________________ 
>dhcwg mailing list 
>[email-masked] 
><http://www1.ietf.org/mailman/listinfo/dhcwg>http://www1.ietf.org/mailman/listinfo/dhcwg 

_______________________________________________
dhcwg mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Nov 2001 11:09:28 -0700

Oy.   Based on your message, I've spent the last twenty minutes or so 
trying to convince myself either that no change is required, or that my 
proposed change is required, and I've tried to integrate my personal 
experience with debugging a pool-balancing problem in the failover protocol 
into that.

You are completely right that POOLREQ is of questionable value.   I have 
seen the problem to which you allude, where it demands a full rebalance, 
and while it's not catastrophic on a server with 10,000 leases I can easily 
imagine it causing problems in a larger deployment.   I think a small 
enhancement to the POOLREQ message would solve this problem - allow the 
sending server to  include a new option, similar to the DHCP Subnet 
Selection option, that tells the recipient what pool the sender wants it to 
rebalance.   This additional locality of reference would probably help to 
reduce thrashing in large environments.   On the other hand, just removing 
the POOLREQ message entirely might be a better choice.

With respect to the primary-controls-pool-balancing model, I can see where 
it is of value now that you've reminded me of the conversations we have.   
I think this is one of those cases where both models have merit, and it's 
easy to flop between them, because the spec is big enough that one tends 
not to remember all the details.   Thanks for keeping good minutes!   :'}