Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00

["Wes Beebee (wbeebee)" <[e-mail]>]

My comments fall under the category of "optimization".

Certainly the client can drop the original transaction and issue another
Information-Request set of messages for the rest of the information
already contained in the original transaction.  Just out of curiosity, why
is this behavior mandated?

While I think this work is very important, I would like to see more
comments from others on the significant changes to the protocol that are
contained in the document.

- Wes

On 9/7/12 12:18 PM, "Bernie Volz (volz)" <[e-mail]> wrote:

>I believe Wes' and Hemant's issues were:
>
>Wes (message on Thu 8/16/2012):
>
>   Why MUST the client ignore an Advertise message with no bindings?
>   What if stateful and stateless options are carried in the same message?
>   Does this mean the stateless options will be ignored just because the
>stateful Options failed?
>
>---
>
>Ole's answer was that basically this is how RFC 3315 operates today and
>we didn't want to change this (we are fixing what happens if IA_NA and
>IA_PD are requested in a Solicit and only one of these is available) --
>which is different than the no bindings at all case. RFC 3315 basically
>expects clients to use Information-Request in this case.
>
>A while back, Ralph and I considered that this might be a good change -
>especially given the case when M says to use stateful but the server is
>not configured to give (the requesting client) any stateful bindings.
>Server could effectively respond with the other configuration options.
>But an Advertise is not the same as a Reply, so if the client was going
>to do a Request/Reply, we'd have to change that processing to and so why
>doesn¹t the client just do an Information-Request? (Sure, if Rapid Commit
>is requested, server would just Reply and client would be done.)
>
>If the WG feels that would be a useful change, we can certainly do this
>change. But for this particular work, we didn't feel that change was
>warranted. And, it might be best to do under a separate document? Or
>something for a 3315bis?
>
>
>Hemant (message on 8/17/2012) and Ole's response (using Ole's email on
>8/20/2012):
>
>> +1 to Wes' comment that this document is addressing a very important
>>problem space and the solutions are needed urgently.  However, more
>>thought is required for the solutions.
>> 
>> In regards to section 4.4, if the server only checks the network
>>configuration to reply to a Confirm message, how is it possible for most
>>network configurations that the server determines an IA_PD is on-link?
>>I suspect that is why RFC 3633 prohibited use of the Confirm for the
>>IA_PD.  In any case this document should explain why did RFC 3633 have a
>>restriction on using the Confirm for the IA_PD.  Or does network
>>configuration include looking up the prefix pool configured on the
>>server for allocation?  In contrast, to make an on-link determination
>>for an IA_NA IA_Address, all the server has to do is match
>>(longest-prefix match) all IPv6 addresses configured on the machine that
>>the server is running on.  These addresses are clearly network
>>configuration.  
>
>right, either the server has the binding, or the server has configuration
>that it can look up in, to verify if the client has moved or not. if it
>has no information it MUST not reply.
>
>> Section 4.1:  
>> 
>> # In relation to the first paragraph the document is addressing the
>>fact that one server replies with, say, an IA_NA, while another server
>>replies back with only the IA_PD.   Then why in section 4.7 the case of
>>section 4.1 is deemed out of scope?   I also do not understand what does
>>"equal" in section 4.7 mean.  Does it mean each server replies with all
>>IAs that the deployment needs?
>
>the assumption in 3315/3633 is that a client is connected to a single
>administrative dhc domain on an interface.
>scenarios where a client finds two DHCP servers, that are administered by
>two different entities, are outside of the scope of 3315/3633 and
>therefore also outside the scope of this update. there is as far as I
>know separate work in progress on this.
>
>> # In relation to the text in the last paragraph of section 4.1, if the
>>client does not restart the Solicit retransmissions timers, what does
>>the client do?
>
>continues with the timers it has.
>otherwise as the text says, a received advertise with a consequent
>restart of solicit timers would result in a solicit storm.
>
>> 
>> # Other comment:  Shouldn't the header of the document have an Updates
>>tag to signify this document updates RFC 3315?
>
>good point. both 3315 and 3633.
>
>---
>
>I guess the one change that I see is to assure we update the document
>header. We can respin the document for this change.
>
>Section 4.4 is just extending the Confirm to include prefixes - this
>issue is already covered in RFC 3315 for Confirm processing:
>
>                                                               If the
>server is unable to perform
>   this test (for example, the server does not have information about
>   prefixes on the link to which the client is connected), or there were
>   no addresses in any of the IAs sent by the client, the server MUST
>   NOT send a reply to the client.
>
>The section 4.1 / 4.7 issue is the single vs multiple provisioning
>domains - we assume a single in this document.
>
>
>If Wes or Hemant would like other changes to clarify any of their
>concerns, we would appreciate text to be added/modified.
>
>- Bernie
>
>-----Original Message-----
>From: Ted Lemon [mailto:[e-mail]]
>Sent: Friday, September 07, 2012 11:38 AM
>To: Bernie Volz (volz)
>Cc: dhc WG
>Subject: Re: WGLC: draft-ietf-dhc-dhcpv6-stateful-issues-00
>
>On Sep 7, 2012, at 11:09 AM, Bernie Volz (volz) <[e-mail]> wrote:
>> Where does this Last Call stand? August 24th has passed ...
>
>There were a lot of comments in the WGLC, and lot of support for what is
>to be accomplished here, but several people raised concerns as well.
>There were a few responses in favor of advancing the current document;
>Hemant Singh had some suggestions, to which Ole responded.   I do not
>know if the responses satisfied Hemant's concerns.   I raised some
>concerns which were not really addressed.   Wes Beebe raised a concern
>which Ole responded to, but again I don't know if Wes was satisfied with
>Ole's response.
>
>
>So I think this is borderline.   There's clearly widespread support for
>what this draft is trying to do; I would like to hear from Hemant and Wes
>as to whether they are satisfied with Ole's responses.   I tend to agree
>with Wes' sentiment that we need to think this through very carefully; I
>would like to see a new draft that addresses Hemant's and Wes' concerns,
>if possible, and then do a second last call to get more review.   Does
>that work for the authors?