Re: [dhcwg] Load Balancing for DHCPv6 -01

>There is still outstanding discussion around whether section 3.1 may apply to all messages, vs. whether a server should always answer a Release and/or Decline.  See discussion between myself and Bernie.

I can't see why this is an open issue for Release/Decline? The other server can't respond as it isn't the server being addressed by the server-id and there is no 'fallback' (i.e., like Rebind for Renew)? And ignoring the packet means leaving the address or prefix leased until it expires.

I think section 3.1 should be clear that it applies to Renew messages. 

There may be more to discuss regarding Request and Information-Request, but ...

The Request is an edge case (as that would be from the Solicit/Advertise/Request/Reply sequence where the partner returned between Advertise and Request). Whether to include Request here is up in the air - it would delay the client getting an address (or prefix) as the client would need to timeout and return to Solicit; whereas having the server continue with the Request would allow the client to complete DHCP immediately and then transition at Renew/Rebind time (though at that time it is still able to use the address or prefix). So I could see this as an implementation choice. In my opinion, I think it better to get the client online quickly (think of MTAs after a power failure and someone needing to place a call!). It also avoids the time-out processing that likely has to occur for the provisionally assigned address or prefix - if the server does that.

Note that the Request parameters are:

   REQ_TIMEOUT       1 sec   Initial Request timeout
   REQ_MAX_RT       30 secs  Max Request timeout value
   REQ_MAX_RC       10       Max Request retry attempts

So, likely this would be 1 + 2 + 4 + 8 + 16 + 30 + 30 + 30 + 30 + 30 = 209 seconds (3.5 minutes) which is a long time to wait before returning to Solicit - especially if it is an emergency call!. So, that is why I think it is a bad idea.

Information-Request, which may have a server-identifier(at least based on section 15 text, though the section 18.1.5 is silent on this matter) is also less clear if it has one as I am not sure what, if any, fallback occurs for that case? And, this is usually a fairly low cost operation so not sure there is a significant benefit in not responding. And, there is no limit to the number of times an Information-Request is transmitted; though that seems like a problem if the server-identifier option is present. Perhaps this is something to clean up in RFC 3315bis -- either don't allow the server-identifier option or if one is included, a retry limit (MRC) should be imposed (with the fallback to remove the option?).

I don't mind if we just explained these options and their implications and leave it to the server implementer to decide what their choice is (or to provide knobs). I can't see that either choice cause a 'severe' failure or interoperability issue - since the server being specified in a server-identifier may not always be available anyway (or could be replaced by another server).

And, even if two servers that were participating in load balancing behaved differently, there would be no issue (in one case, the clients transition; in the others they don't).

--

A minor nit in section 3 you say "... with the following two differences." But 3 sections follow (3.1, 3.2, 3.3). Perhaps best to just drop "two"?

- Bernie

-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Andre Kostur
Sent: Monday, September 24, 2012 2:57 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Load Balancing for DHCPv6 -01

Dear all:

I have submitted an updated I-D updating RFC 3074 to apply to DHCPv6.

The text is available at:
http://www.ietf.org/internet-drafts/draft-kostur-dhc-loadbv6-01.txt

Major changes:

Added a new Section 3.1 to discuss the requests with a Server ID specified.

Modified the specification of the STID to remove the restriction to 16 bytes.

Remaining currently outstanding item:

There is still outstanding discussion around whether section 3.1 may apply to all messages, vs. whether a server should always answer a Release and/or Decline.  See discussion between myself and Bernie.

Comments and suggestions welcome.   I am looking to have the WG take
this on as a work item.

--
Andre Kostur
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg