Re: [dhcwg] Comments on draft-ietf-dhc-dhcpv6-failover-design-02

[Kim Kinnear <[e-mail]>]

Folks,

The quote markers are off in the previous email with 
similar content -- my apologies.  Here is the same email,
with corrected quote markers (which should make it more
obvious what I was saying vs what Marcin was saying).

Regards -- Kim

On Aug 9, 2013, at 10:54 AM, Kim Kinnear wrote:


Marcin,

*Now* I understand where the confusion is coming from.  See below...

On Aug 7, 2013, at 6:17 AM, Marcin Siodelski wrote:

> 
>> 9.11. RESOLUTION-INTERRUPTED
>> - In the introduction to this chapter it is pointed out that if the
>> server's remained in the POTENTIAL-CONFLICT state and the resolution of
>> the conflict was interrupted, they transition to RESOLUTION-INTERRUPTED
>> and they are unresponsive to clients

	This is simply not true -- the document does not say this.
	See below...
> 
>        I don't see the statement about being unresponsive to clients.
>        Could you point me at it more specifically?
> 
> Here is an exact citation from this section:
> 
> " This state indicates that the two servers were attempting to
> reintegrate with each other in POTENTIAL-CONFLICT state, but
> communications failed prior to completion of re-integration.
> 
> If the servers remained in POTENTIAL-CONFLICT while communications
> was interrupted, neither server would be responsive to DHCP client
> requests, and if one server had crashed, then there might be no
> server able to process DHCP requests."

	This second paragraph is conditional -- "If" the servers
	remained in POTENTIAL-CONFLICT "then" neither server
	would be responsive to DHCP client requests.  This is the
	justification for the RESOLUTION-INTERRUPTED failover
	state, this is *not* the description of how the server
	operates in the RESOLUTION-INTERRUPTED state.  That is
	explained in section 9.11.1.

	Since the servers do *not* remain in POTENTIAL-CONFLICT
	state, they do not have to be unresponsive to DHCP client
	requests.  They do not have to be responsive, either.

	The statement above says *nothing* about whether or not
	they are responsive to client requests in the
	RESOLUTION-INTERRUPTED state, it simply motivates *why*
	there is a RESOLUTION-INTERRUPTED state.

	See below...


> 
> 
> When I said that "they are unresponsive to clients" I was referring to this part of the cited text: "... neither server would be responsive to DHCP client requests..."
> 
> 
> 
>> (I presume this is because they
>> were unresponsive when being in POTENTIAL-CONFLICT state and the
>> conflict is still assumed to be present).
> 
>        No, not really.  That is the point of RESOLUTION-INTERRUPTED
>        state -- they can attempt to do *something*, and not just
>        sit there waiting for the partner.
> 
> Ok. So, what they do? They rise an alarm as stated in the last paragraph of 9.11.
> But still, my understanding is that servers are unresponsive to clients as stated in the "... neither server would be responsive to DHCP client requests...".  (see above).
> 
> 
>> If you take a look at the
>> 9.11.1. it is said that the server MUST respond to all DHCP client
>> requests. That looks contrary to the previous statement.

	Section 9.11.1 is titled "Operation in
	RESOLUTION-INTERRUPTED State", and is quite explicit that
	the servers MUST respond to all DHCP client requests.

	It is not in conflict with any previous statement,
	because 9.11 says exactly *nothing* with regard to
	whether or not a server in RESOLUTION-INTERRUPTED state
	should process DHCP client requests.

	See below...
> 
>        Indeed, but I can't find the previous statement...
> 
> Cited above.
> 
>> My
>> understanding is that the server can't respond in the
>> RESOLUTION-INTERRUPTED state thus it requires administrative
>> intervention.
> 
>        I don't know where in the document you got that idea
>        from, but I'd like to fix it.
> 

	So, technically, I think the document is accurate and
	that there is no conflict in what is described.

	That said, you obviously found it obscure enough to raise
	this issue, and when we revise the document the next
	time, I will add some words to Section 9.11 to try to
	clarify that we are motivating the existence of the
	RESOLUTION-INTERRUPTED state, not describing how it
	operates.

	I think that would help clarify this situation.

	Regards -- Kim