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

From: Marcin Siodelski <[email-masked]>
Date: Wed, 7 Aug 2013 12:17:44 +0200

Kim and Tomek,

Thanks for addressing my comments. Below I clarified some of the comments
with respect to section 9.11. It may be the case that I misunderstood the
part regarding unresponsiveness in the Resolution-Interrupted state. I am
hoping that my point will be clearer to you with the additional info below.

> 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
>
>         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."

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.
>
>         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.
>

See above.

Marcin

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 9 Aug 2013 10:54:40 -0400

Marcin,

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

> > and they are unresponsive to clients

	This is simply not true -- the document does not say this.
	See below...

> 	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..."
> 
> 
>  
> 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).
>  
> 

	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...
>         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

---

From: Kim Kinnear <[email-masked]>
Date: Fri, 9 Aug 2013 11:06:10 -0400

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,

	See below...

	See below...

	Regards -- Kim