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.
- Inter-server Protocol for DHCP Bo Ahlberg
- Re: Inter-server Protocol for DHCP Robert G. Cole