Inter-server Protocol for DHCP

Bo Ahlberg <BoA@metainfo.com> Wed, 26 March 1997 01:41 UTC

Received: from cnri by ietf.org id aa07259; 25 Mar 97 20:41 EST
Received: from marge.bucknell.edu by CNRI.Reston.VA.US id aa25567; 25 Mar 97 20:41 EST
Received: from reef.bucknell.edu by mail.bucknell.edu; (5.65v3.2/1.1.8.2/17Jul96-0109PM) id AA12675; Tue, 25 Mar 1997 20:33:40 -0500
Date: Tue, 25 Mar 1997 20:33:40 -0500
Message-Id: <c=US%a=_%p=MetaInfo%l=LEGO-970324195607Z-17837@lego.metainfo.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: Bo Ahlberg <BoA@metainfo.com>
To: Multiple recipients of list <dhcp-v4@bucknell.edu>
Subject: Inter-server Protocol for DHCP
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: Discussion of DHCP for IPv4
X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.838.14

Good job..... excellent first draft....

Overall comments:



Here's some questions....:

Section 3 Peer Redundant Server Models:

In sub-section 3.1  and Sub-Section 4.1 Paragraph 2 Pg. 16 

Is it necessary for the LS to wait for an acknowledgement from a DCS so
as to prevent a failure of the LS to register a cache state change with
the SG due to an LS crash?
(I am assuming it is. Am I wrong?)

Responses to questions:
sub-section 4.4
Question 1.("Can the cache alignment process be 'simultaneously'...")
I believe that this is essential... If one member of the SG determines
that the Primary has "failed" it must initiate an election for Primary.
As part of the election process the SG will attempt to discover which LS
are still responding, synchronize their caches and elect the new
primary. This may cause a short "outage" of service... But short of
implementing the PRSM model, there will always some "small" period of
service "outage".

Suggestions:

As to the Address Redistribution Procedure:
Possibly the "first initiating" LS should be "elected" the arbitrator
for the members of an SG (or maybe the first "requested" DCS) which
collects the state of the "unallocated"  pool for the SG and assigns
"shares" to each member of the SG. The "share" could be determined by
each LS declaring it available "unallocated" pool and requesting a
specific "share" of the pool.  The "arbitrating" LS then makes
assignments. 

Upside: Would allow for dynamic distribution of addresses. Would allow
for whole pools to be distributed not just the "shares" of specific
server pairs. Would prevent "cascade" events when Srv-A asks  Srv-B to
"share" which causes Srv-B to ask Srv-C to "share".....

Downside: potentially time consuming process. Complex interactions and
code. Doesn't deal effectively with miss-tuned LSes.

As to "Primary Election" sub-section 4.3
You could use a rule based upon the method used by the MX record in the
DNS. Each LS in an SG could be assigned a "priority" value, the LS with
the lowest "priority" value would be the primary... and upon failure the
next lowest would be "elected".


Editorial Comments:

sub-section 2.2.2
Associated paragraph starts with a lower case. Sentence is incomplete.
sub-section 3.1 paragraph 3
Paragraph has a few incomplete sentences.