Re: [dhcwg] Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)

[Ted Lemon <[e-mail]>]

The database write is on the server.   This is an existing characteristic
of DHCP servers, not something new in this draft.   The point of this draft
is to _avoid_ the database write, as well as the possibility of renumbering.

On Wed, May 4, 2016 at 4:46 PM, Mudric, Dusan (Dusan) <[e-mail]>
wrote:

> Can the authors of this proposal clarify “DHCPINFORM does not require a
> database write.   DHCPREQUEST does” please? What kind of database are you
> talking about? A database on the DHCP client device? If so, isn’t device
> going to be reconfigured after DHCPINFORM and its database updated?
>
>
>
> Are there other advantages, in addition to the performance advantage? For
> example, when is it important to immediately apply the DHCP server
> configuration changes, vs at T1?
>
>
>
> Thanks,
>
> Dusan.
>
>
>
> *From:* Ted Lemon [mailto:[e-mail]]
> *Sent:* Wednesday, May 04, 2016 3:53 PM
>
> *To:* Mudric, Dusan (Dusan)
> *Cc:* Tomek Mrugalski; [e-mail]
> *Subject:* Re: [dhcwg] Adoption Call for
> draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)
>
>
>
> I'm not the author of the document.   I was present in Buenos Aires for
> the presentation.   The presentation was convincing.   To briefly answer
> your questions, DHCPINFORM does not require a database write.   DHCPREQUEST
> does.   Forcerenew nonce is a very cheap authentication scheme--there is no
> digital signature.
>
>
>
> That said, if you are resisting this proposal, it may be because it
> doesn't make sense for your devices.   The authors of this proposal don't
> intend that it be applicable to all use cases, and in particular
> (admittedly with an outsider's knowledge) I do not see why this would be a
> useful feature to add to an Avaya product.   That's what applicability
> statements are for.
>
>
>
> I suppose you could do your best to just kill this proposal so that you
> don't have to implement it, but given that there is an identified need for
> this in a real-world deployment, doing so would be creating a hassle for
> someone else.   So it woudl be better, if you don't mind, to focus your
> efforts on making sure that the applicability statement for this document
> doesn't cover devices that you think it should not cover.
>
>
>
>
>
> On Wed, May 4, 2016 at 3:05 PM, Mudric, Dusan (Dusan) <[e-mail]>
> wrote:
>
> If this was the answer, “being able to get the client to refresh its
> config information without updating its lease is a substantial savings”,
> why is IPv4 address update so much more demanding than the DHCPv4
> DHCPFORCEINFORENEW with authentication? Can you provide more details please
> (impacts on DHCPv4 server, clients, network)?
>
>
>
> Dusan
>
>
>
> *From:* Ted Lemon [mailto:[e-mail]]
> *Sent:* Wednesday, May 04, 2016 2:26 PM
>
>
> *To:* Mudric, Dusan (Dusan)
> *Cc:* Tomek Mrugalski; [e-mail]
> *Subject:* Re: [dhcwg] Adoption Call for
> draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)
>
>
>
> I already answered that question in my previous reply.
>
>
>
> On Wed, May 4, 2016 at 2:06 PM, Mudric, Dusan (Dusan) <[e-mail]>
> wrote:
>
> This is the only reference I found
> https://www.ietf.org/proceedings/95/slides/slides-95-dhc-6.pdf
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_proceedings_95_slides_slides-2D95-2Ddhc-2D6.pdf&d=CwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=BzvF_BAx29HABskqTZPToA36ycN_GkeEca5PoEZADao&s=xYGBNGgztvEiaK2mg5zgFTmOG8pRT2D4chP58XUawMc&e=>
> . It does not talk about the problems when RECONFIGURE is not supported.
> The DHCP clients can get the new configuration parameters during the RENEW,
> at T1. Why is this not good enough and which deployment scenarios require
> immediate updates using RECONFIGURE?
>
>
>
> Dusan
>
>
>
> *From:* Ted Lemon [mailto:[e-mail]]
> *Sent:* Wednesday, May 04, 2016 1:52 PM
>
>
> *To:* Mudric, Dusan (Dusan)
> *Cc:* Tomek Mrugalski; [e-mail]
> *Subject:* Re: [dhcwg] Adoption Call for
> draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)
>
>
>
> It's in the IETF 95 proceedings.
>
>
>
> On Wed, May 4, 2016 at 1:27 PM, Mudric, Dusan (Dusan) <[e-mail]>
> wrote:
>
> Is there a link  to that presentation? Are there problem statements for
> cloud deployments?
>
>
>
> Thanks,
>
> Dusan.
>
>
>
> *From:* Ted Lemon [mailto:[e-mail]]
> *Sent:* Wednesday, May 04, 2016 1:13 PM
> *To:* Mudric, Dusan (Dusan)
> *Cc:* Tomek Mrugalski; [e-mail]
>
>
> *Subject:* Re: [dhcwg] Adoption Call for
> draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)
>
>
>
> There was a detailed presentation on this in Buenos Aires.   The bottom
> line is that if you have a large number of devices, the additional load of
> updating the database for every forcerenew becomes substantial, and being
> able to get the client to refresh its config information without updating
> its lease is a substantial savings.
>
>
>
> On Wed, May 4, 2016 at 1:09 PM, Mudric, Dusan (Dusan) <[e-mail]>
> wrote:
>
> Hi,
>
> Can somebody please provide examples of deployment needs for DHCPv6
> RECONFIGURE message (or DHCPv4 DHCPFORCEINFORENEW), for both stateful and
> stateless DHCPv6 clients?
>
> Regards,
> Dusan Mudric.
>
> -----Original Message-----
> From: dhcwg [mailto:[e-mail]] On Behalf Of Tomek Mrugalski
> Sent: Wednesday, May 04, 2016 12:42 PM
> To: [e-mail]
> Subject: Re: [dhcwg] Adoption Call for
> draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)
>
> Good DHC people,
>
> This is just a reminder that we have adoption call in progress, but so far
> the number of responses is... disappointing. This is a very short (4 pages
> of technical text) I-D. Please take a quick look and state whether you're
> ok with it. Or better yet, review it thoroughly and post your comments.
> Your opinion and your comments are much appreciated.
>
> The adoption call will end early next week.
>
> With my co-chair hat off, I support adoption of this draft. It is short,
> well motivated (good explanation what the problem is and why it needs
> solving) and reasonable draft. In my opinion it simply introduces parity
> between DHCPv6 and DHCPv4 (v6 has the capability to reconfigure options
> only since RFC3315 was published in 2003). This mechanism has been around
> for well over a decade and is operationally proven to work.
>
> Tomek
>
> On 22.04.2016 16:48, Bernie Volz (volz) wrote:
> > Hi:
> >
> > At the IETF-95 DHC WG session, Luyuan Fang gave a presentation on
> > draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Forcerenew
> > Reconfiguration Extensions for DHCPv4) - see
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_proceedings_95_slides_slides-2D95-2Ddhc-2D6.pdf&d=CwIF-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=9AtpUL6fIYzFJHKD_D34cbLaSr7UfQJoVnHqCCSc3iI&s=fdrSa2jxD0SbN3vaFTNMwWC_yclWLZ8spS0pKJEMjx4&e=
> .
> >
> > There was a brief discussion about whether there was sufficient
> > interest in the WG to take on this work and the conclusion was to take
> > it to the list (which we would have needed to do anyway).
> >
> > So, we are starting an Adoption Call for this draft
> > (
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dfang-2Ddhc-2Ddhcpv4-2Dforcerenew-2Dextensions-2D02&d=CwIF-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=9AtpUL6fIYzFJHKD_D34cbLaSr7UfQJoVnHqCCSc3iI&s=so5zarbh0Ii_cWj1iC6ifCVWHmBw4WeoVLdfUi7fu9E&e=
> ).
> >
> > Please respond by May 8, 2016 whether you support having the WG take
> > on this work. Please note that this means YOU need to be involved in
> > resolving open issues, reading draft updates, and otherwise actively
> > participating to move this work forward.
> >
> > The abstract from the draft is:
> >
> >    This document extends the definition of the DHCPFORCERENEW message
> >    for parameter reconfiguration in DHCPv4. This extension makes the
> >    DHCPFORCERENEW message more suitable to reconfigure configuration
> >    parameters other than IP addresses, and aligns the behavior of the
> >    reconfiguration procedure in DHCPv4 to the corresponding behavior in
> >    DHCPv6.
> >
> > While not directly on the WG's current charter, we have confirmed with
> > our AD (Suresh) that this would be acceptable work for us to adopt (no
> > re-chartering will be necessary).
> >
> > -          Tomek and Bernie
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dhcwg&d=CwIF-g&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=9AtpUL6fIYzFJHKD_D34cbLaSr7UfQJoVnHqCCSc3iI&s=PVv9LskHr2eCb4z-MQ6MzHHJxv7ehdNMUO9uhkCGxZk&e=
>
>
> _______________________________________________
> dhcwg mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dhcwg
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dhcwg&d=CwMFaQ&c=BFpWQw8bsuKpl1SgiZH64Q&r=UT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY&m=IMp0tLq-MuNu9erA4e0AQLU6-UlKPST4lFi_Kde9q4E&s=ilLHNVHnEv3M03ZNFRr9_q6JrgYyuXBCxSvinBLLdQY&e=>
>
>
>
>
>
>
>
>
>