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

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 4 May 2016 18:42:25 +0200

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://www.ietf.org/proceedings/95/slides/slides-95-dhc-6.pdf.
> 
> 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://tools.ietf.org/html/draft-fang-dhc-dhcpv4-forcerenew-extensions-02).
> 
> 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

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 4 May 2016 17:09:35 +0000

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:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Wednesday, May 04, 2016 12:42 PM
To: [email-masked]
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.

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:
> 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).
> 
> (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 
> While not directly on the WG's current charter, we have confirmed with 

_______________________________________________
dhcwg mailing list
[email-masked]
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=

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 May 2016 13:12:59 -0400

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) <[email-masked]>
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.
>
> 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.
>
> only since RFC3315 was published in 2003). This mechanism has been around
> for well over a decade and is operationally proven to work.
>
> Tomek
>
> > (
> 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=
> ).
> >
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 4 May 2016 17:27:15 +0000

Is there a link  to that presentation? Are there problem statements for cloud deployments?

Thanks,
Dusan.

From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, May 04, 2016 1:13 PM
To: Mudric, Dusan (Dusan)
Cc: Tomek Mrugalski; [email-masked]
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) <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,
Dusan Mudric.

-----Original Message-----
From: dhcwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tomek Mrugalski
Sent: Wednesday, May 04, 2016 12:42 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)

Good DHC people,

Tomek

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
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
[email-masked]<mailto:[email-masked]>
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=>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 May 2016 13:52:09 -0400

It's in the IETF 95 proceedings.

On Wed, May 4, 2016 at 1:27 PM, Mudric, Dusan (Dusan) <[email-masked]>
wrote:

> *From:* Ted Lemon [mailto:[email-masked]]
> *Sent:* Wednesday, May 04, 2016 1:13 PM
> *To:* Mudric, Dusan (Dusan)
> *Cc:* Tomek Mrugalski; [email-masked]
>
> *Subject:* Re: [dhcwg] Adoption Call for
> <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=>
>
>
>

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 4 May 2016 18:06:23 +0000

This is the only reference I found https://www.ietf.org/proceedings/95/slides/slides-95-dhc-6.pdf . 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

Sent: Wednesday, May 04, 2016 1:52 PM

On Wed, May 4, 2016 at 1:27 PM, Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>> wrote:
Is there a link  to that presentation? Are there problem statements for cloud deployments?

Thanks,
Dusan.

From: Ted Lemon [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, May 04, 2016 1:13 PM
To: Mudric, Dusan (Dusan)
Cc: Tomek Mrugalski; [email-masked]<mailto:[email-masked]>

Regards,
Dusan Mudric.

-----Original Message-----
From: dhcwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tomek Mrugalski
Sent: Wednesday, May 04, 2016 12:42 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)

Good DHC people,

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 May 2016 14:25:37 -0400

I already answered that question in my previous reply.

On Wed, May 4, 2016 at 2:06 PM, Mudric, Dusan (Dusan) <[email-masked]>
wrote:

> This is the only reference I found
> https://www.ietf.org/proceedings/95/slides/slides-95-dhc-6.pdf . 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
>
>
>
> *Sent:* Wednesday, May 04, 2016 1:52 PM
>

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 4 May 2016 19:05:37 +0000

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

Sent: Wednesday, May 04, 2016 2:26 PM

On Wed, May 4, 2016 at 2:06 PM, Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>> 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

Thanks,
Dusan.

Regards,
Dusan Mudric.

-----Original Message-----
From: dhcwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tomek Mrugalski
Sent: Wednesday, May 04, 2016 12:42 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)

Good DHC people,

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 May 2016 15:52:37 -0400

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) <[email-masked]>
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
>
>
>
> *Sent:* Wednesday, May 04, 2016 2:26 PM
>
> 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

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Wed, 4 May 2016 20:46:18 +0000

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.

Sent: Wednesday, May 04, 2016 3:53 PM

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) <[email-masked]<mailto:[email-masked]>> 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

Dusan

Thanks,
Dusan.

Regards,
Dusan Mudric.

-----Original Message-----
From: dhcwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tomek Mrugalski
Sent: Wednesday, May 04, 2016 12:42 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)

Good DHC people,

Tomek

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 May 2016 17:10:49 -0400

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) <[email-masked]>
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.
>
>
>
> *Sent:* Wednesday, May 04, 2016 3:53 PM
>
> 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
> 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.
>
>
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 5 May 2016 18:19:32 +0000

Also, just because an RFC exists, doesn’t mean you have to support it – that’s pretty common for new features and things that may not be applicable to all devices (RFC 3118 has probably not been implemented by many).

Sure, there may be future RFPs that list all “DHCP” related specifications (checkbox items, perhaps even competitors use it to cause others to be non-conformant).

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Wednesday, May 04, 2016 3:53 PM
To: Mudric, Dusan (Dusan) <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)

Dusan

Dusan

Thanks,
Dusan.

Regards,
Dusan Mudric.

-----Original Message-----
From: dhcwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tomek Mrugalski
Sent: Wednesday, May 04, 2016 12:42 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)

Good DHC people,

Tomek

---

From: "Mudric, Dusan (Dusan)" <[email-masked]>
Date: Thu, 5 May 2016 19:12:46 +0000

It is not about the support for the extension of DHCPv6 RECONFIGURE to DHCPv4. Just trying to find out real use case scenarios or problem statements where this feature is important. Personally, I think the DHCPFORCEINFORENEW is very good idea. However, it will gain more significance if there are feedbacks from the DHCP users.

Thanks,
Dusan.

From: Bernie Volz (volz) [mailto:[email-masked]]
Sent: Thursday, May 05, 2016 2:20 PM
To: Ted Lemon; Mudric, Dusan (Dusan)
Cc: [email-masked]
Subject: RE: [dhcwg] Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Wednesday, May 04, 2016 3:53 PM
To: Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)

Dusan

Dusan

Thanks,
Dusan.

Regards,
Dusan Mudric.

-----Original Message-----
From: dhcwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tomek Mrugalski
Sent: Wednesday, May 04, 2016 12:42 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)

Good DHC people,

Tomek

---

From: Linhui Sun <[email-masked]>
Date: Sun, 8 May 2016 22:30:49 +0800

Hi,

I did read this document (version 01) and give some comments before. I
think it is a useful solution and support it to be adopted.

Regards,
Linhui

2016-04-22 22:48 GMT+08:00 Bernie Volz (volz) <[email-masked]>:

> draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Forcerenew Reconfiguration
> Extensions for DHCPv4) – see
> So, we are starting an Adoption Call for this draft (
> https://tools.ietf.org/html/draft-fang-dhc-dhcpv4-forcerenew-extensions-02
> ).
>
>
>
> 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.
>
>
>
> 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

---

From: Lishan Li <[email-masked]>
Date: Sun, 8 May 2016 22:53:13 +0800

Dear All,

I have reviewed the draft. And I am in favor of adopting this work as a  DHC
WG item.

Best Regards,
Lishan

---

From: Luyuan Fang <[email-masked]>
Date: Tue, 10 May 2016 08:11:29 +0000

Hi all,

Thanks for your discussion. I support the adoption of the draft as co-author.

As DHCP users, the use case for the proposed Forcerenew Reconfiguration Extension for DHCPv4 comes from our hyper-scale Cloud operation. In small scale environment, the proposed Forcerenew Reconfiguration Extension for DHCPv4 can be viewed as optimization, nice to have to align with DHCPv6. In hyper-scale cloud, we are dealing with million+ servers, provisioning 1000+ new customers each day, everything is under different light. This improvement becomes necessity for keeping customer sessions up, and keeping the DC operation manageable – when only reconfig is needed, we don’t want to renew the DHCP session which runs the risk of losing the session, which is very bad for our cloud customers, and consumes network and especially devops resources for trouble shooting.

The details are in slides we presented in IETF 95, the link is in Bernie’s call for adoption email, can also be download at https://datatracker.ietf.org/meeting/95/materials.html/ (look for dhc session, Forcerenew Reconfiguration Extensions for DHCPv4<https://www.ietf.org/proceedings/95/slides/slides-95-dhc-6.pdf>).

Thanks,
Luyuan

From: dhcwg [mailto:[email-masked]] On Behalf Of Mudric, Dusan (Dusan)
Sent: Thursday, May 5, 2016 12:13 PM
To: Bernie Volz (volz) <[email-masked]>; Ted Lemon <[email-masked]>
Cc: [email-masked]
Subject: Re: [dhcwg] Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)

Thanks,
Dusan.

-          Bernie

Dusan

On Wed, May 4, 2016 at 2:06 PM, Mudric, Dusan (Dusan) <[email-masked]<mailto:[email-masked]>> wrote:
This is the only reference I found https://www.ietf.org/proceedings/95/slides/slides-95-dhc-6.pdf<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2furldefense.proofpoint.com%2fv2%2furl%3fu%3dhttps-3A__www.ietf.org_proceedings_95_slides_slides-2D95-2Ddhc-2D6.pdf%26d%3dCwMFaQ%26c%3dBFpWQw8bsuKpl1SgiZH64Q%26r%3dUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY%26m%3dBzvF_BAx29HABskqTZPToA36ycN_GkeEca5PoEZADao%26s%3dxYGBNGgztvEiaK2mg5zgFTmOG8pRT2D4chP58XUawMc%26e%3d&data=01%7c01%7clufang%40microsoft.com%7c1f3827cbedbf4295669608d375194563%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=NIybng6%2bzRG0rgeDCdqqruy8TxK7TcAMa2uiIvVYQlU%3d> . 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

Thanks,
Dusan.

Regards,
Dusan Mudric.

-----Original Message-----
From: dhcwg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Tomek Mrugalski
Sent: Wednesday, May 04, 2016 12:42 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)

Good DHC people,

Tomek

On 22.04.2016 16:48, Bernie Volz (volz) wrote:
> 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=<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2furldefense.proofpoint.com%2fv2%2furl%3fu%3dhttps-3A__www.ietf.org_proceedings_95_slides_slides-2D95-2Ddhc-2D6.pdf%26d%3dCwIF-g%26c%3dBFpWQw8bsuKpl1SgiZH64Q%26r%3dUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY%26m%3d9AtpUL6fIYzFJHKD_D34cbLaSr7UfQJoVnHqCCSc3iI%26s%3dfdrSa2jxD0SbN3vaFTNMwWC_yclWLZ8spS0pKJEMjx4%26e%3d&data=01%7c01%7clufang%40microsoft.com%7c1f3827cbedbf4295669608d375194563%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=nVz4Ljq14KB2iUsbqmoStkEwTzhQqKaERyXrCZ%2bB8I8%3d> .
>
> (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=<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2furldefense.proofpoint.com%2fv2%2furl%3fu%3dhttps-3A__tools.ietf.org_html_draft-2Dfang-2Ddhc-2Ddhcpv4-2Dforcerenew-2Dextensions-2D02%26d%3dCwIF-g%26c%3dBFpWQw8bsuKpl1SgiZH64Q%26r%3dUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY%26m%3d9AtpUL6fIYzFJHKD_D34cbLaSr7UfQJoVnHqCCSc3iI%26s%3dso5zarbh0Ii_cWj1iC6ifCVWHmBw4WeoVLdfUi7fu9E%26e%3d&data=01%7c01%7clufang%40microsoft.com%7c1f3827cbedbf4295669608d375194563%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=GHzQVQp%2bZ58jn9TiMzGBlC%2bd7N1%2foVD43AMlpZs86hQ%3d> ).
>

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
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=<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2furldefense.proofpoint.com%2fv2%2furl%3fu%3dhttps-3A__www.ietf.org_mailman_listinfo_dhcwg%26d%3dCwIF-g%26c%3dBFpWQw8bsuKpl1SgiZH64Q%26r%3dUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY%26m%3d9AtpUL6fIYzFJHKD_D34cbLaSr7UfQJoVnHqCCSc3iI%26s%3dPVv9LskHr2eCb4z-MQ6MzHHJxv7ehdNMUO9uhkCGxZk%26e%3d&data=01%7c01%7clufang%40microsoft.com%7c1f3827cbedbf4295669608d375194563%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=AezSDqRfwYGlcjoGBsHNu7QSlwRnA1SHwj87YFdB7Q8%3d>

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2furldefense.proofpoint.com%2fv2%2furl%3fu%3dhttps-3A__www.ietf.org_mailman_listinfo_dhcwg%26d%3dCwMFaQ%26c%3dBFpWQw8bsuKpl1SgiZH64Q%26r%3dUT3Bk9cbLeaJxhf3iCrhIoUWB8YLZU23029sMQGQ2kY%26m%3dIMp0tLq-MuNu9erA4e0AQLU6-UlKPST4lFi_Kde9q4E%26s%3dilLHNVHnEv3M03ZNFRr9_q6JrgYyuXBCxSvinBLLdQY%26e%3d&data=01%7c01%7clufang%40microsoft.com%7c1f3827cbedbf4295669608d375194563%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=YxKOHQFLbUtQgsab3D5RH9eOGvCMdNvfEYcp0yYPPnQ%3d>

---

From: "Deepak Bansal (AZURE)" <[email-masked]>
Date: Tue, 10 May 2016 15:58:50 +0000

I support this call. It solves a real world problem in cloud where VM availability is of paramount importance and any glitches in VM connectivity must be avoided - yet the platform must update configuration in accordance with operational needs. It is a simple change that helps cloud scenarios tremendously. Thanks.

PS: I am co-author of this draft.

-----Original Message-----
From: Luyuan Fang 
Sent: Tuesday, May 10, 2016 8:47 AM
To: Deepak Bansal (AZURE) <[email-masked]>
Subject: FW: [dhcwg] Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Wednesday, May 4, 2016 9:42 AM
To: [email-masked]
Subject: Re: [dhcwg] Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)

Good DHC people,

Tomek

On 22.04.2016 16:48, Bernie Volz (volz) wrote:
> https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fproceedings%2f95%2fslides%2fslides-95-dhc-6.pdf&data=01%7c01%7clufang%40microsoft.com%7ccba203e9bcb24a8afc3008d3743c6d80%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=n9pPn9q0GVMvwyBoCBv4kxdOxtDvxt1RSqusvmE3yOo%3d.
> 
> (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-fang-dhc-dhcpv4-forcerenew-extensions-02&data=01%7c01%7clufang%40microsoft.com%7ccba203e9bcb24a8afc3008d3743c6d80%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=%2bckxK7JVVgxJprTYRKp9EfYMnQeLnfcMQWjhISsIGr0%3d).
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fdhcwg&data=01%7c01%7clufang%40microsoft.com%7ccba203e9bcb24a8afc3008d3743c6d80%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=EJSiG6YzDLYuOAxtt%2bXmhSFu5fMlTKVyFU%2b7ntBW4l0%3d

---

From: Tomek Mrugalski <[email-masked]>
Date: Wed, 11 May 2016 18:27:34 +0200

> participating to move this work forward.
Bernie and I had discussed the feedback we received for this adoption
call. There were many supportive voices and nobody objected, so we
declare this draft to be adopted. Thank you to all who had responded.

Authors, thank you for working on this draft. Please re-upload it as WG
item.

Bernie & Tomek

---

From: Luyuan Fang <[email-masked]>
Date: Fri, 13 May 2016 13:36:26 +0000

Tomek and Bernie,

Thank you, and thanks to everyone for your support! 
We up-loaded it as WG item.
https://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-forcerenew-extensions-00

Luyuan

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Wednesday, May 11, 2016 9:28 AM
To: [email-masked]
Subject: [dhcwg] Adoption call summary for draft-fang-dhc-dhcpv4-forcerenew-extensions-02: adopted

On 22.04.2016 16:48, Bernie Volz (volz) wrote:
> (https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2ftools.ietf.org%2fhtml%2fdraft-fang-dhc-dhcpv4-forcerenew-extensions-02&data=01%7c01%7clufang%40microsoft.com%7cbfbe2fc72e2f4a60a2c808d379b92e98%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=MaV1udCufyzo%2fa%2fx6ix%2f0uT7pEhcThzjs305XtvDFZM%3d).
> 
Bernie and I had discussed the feedback we received for this adoption call. There were many supportive voices and nobody objected, so we declare this draft to be adopted. Thank you to all who had responded.

Authors, thank you for working on this draft. Please re-upload it as WG item.

Bernie & Tomek

_______________________________________________
dhcwg mailing list
[email-masked]
https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2fdhcwg&data=01%7c01%7clufang%40microsoft.com%7cbfbe2fc72e2f4a60a2c808d379b92e98%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=eH%2fknYpUJnkaIf8%2bkgCXFEEAFP%2bODXzeQXOs%2bFYV7mM%3d