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

"Mudric, Dusan (Dusan)" <dmudric@avaya.com> Wed, 04 May 2016 19:05 UTC

Return-Path: <dmudric@avaya.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE4D012D1E4 for <dhcwg@ietfa.amsl.com>; Wed, 4 May 2016 12:05:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.926
X-Spam-Level:
X-Spam-Status: No, score=-5.926 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5A1ni64PIaA for <dhcwg@ietfa.amsl.com>; Wed, 4 May 2016 12:05:41 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08DD712D114 for <dhcwg@ietf.org>; Wed, 4 May 2016 12:05:40 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A2DeAQB6RypX/xUHmMZeGQEBAQGCTyErU30GuWQBDYFnDxcBCYVvAhyBHjgUAQEBAQEBAWUnhEEBAQEBAQIBAQEPCwYKQQsMBAIBCA0BAwQBAQEKFgcDAgICJQsUCQgCBA4FCBqICAENogyKUJB/AQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYhhEyBOYJwGBUfCIJCK4IuBZMkhHUBhXuKBE6Df4MdhUGGJokOHgEBQoFMaoE1bAEBAYc6AX4BAQE
X-IPAS-Result: A2DeAQB6RypX/xUHmMZeGQEBAQGCTyErU30GuWQBDYFnDxcBCYVvAhyBHjgUAQEBAQEBAWUnhEEBAQEBAQIBAQEPCwYKQQsMBAIBCA0BAwQBAQEKFgcDAgICJQsUCQgCBA4FCBqICAENogyKUJB/AQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYhhEyBOYJwGBUfCIJCK4IuBZMkhHUBhXuKBE6Df4MdhUGGJokOHgEBQoFMaoE1bAEBAYc6AX4BAQE
X-IronPort-AV: E=Sophos;i="5.24,578,1454994000"; d="scan'208,217";a="173636503"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 04 May 2016 15:05:39 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 04 May 2016 15:05:40 -0400
Received: from AZ-US1EXMB03.global.avaya.com ([fe80::a5d3:ad50:5be9:1922]) by AZ-US1EXHC04.global.avaya.com ([135.11.85.15]) with mapi id 14.03.0174.001; Wed, 4 May 2016 15:05:38 -0400
From: "Mudric, Dusan (Dusan)" <dmudric@avaya.com>
To: Ted Lemon <mellon@fugue.com>
Thread-Topic: [dhcwg] Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)
Thread-Index: AQHRpiVXZmNtwCEKQ0GzVlF2gQQKjp+pAbMQgABFeoD//8CVMIAASl2A//+/0BCAAEmJgP//xvdA
Date: Wed, 04 May 2016 19:05:37 +0000
Message-ID: <9142206A0C5BF24CB22755C8EC422E457A8F7E2F@AZ-US1EXMB03.global.avaya.com>
References: <00f1ca4f5ef14b5f9fa2a2cdd587ba25@XCH-ALN-003.cisco.com> <572A2671.4010602@gmail.com> <9142206A0C5BF24CB22755C8EC422E457A8F7D16@AZ-US1EXMB03.global.avaya.com> <CAPt1N1kjT9nfq3w5JpnWuj_w_3480kUmfWAOt7A_e9EMp0OjCQ@mail.gmail.com> <9142206A0C5BF24CB22755C8EC422E457A8F7D69@AZ-US1EXMB03.global.avaya.com> <CAPt1N1=B2EqH=vm6VBaekoXNYdJVv7dvtK07YxsdtkHau8dcfg@mail.gmail.com> <9142206A0C5BF24CB22755C8EC422E457A8F7DA3@AZ-US1EXMB03.global.avaya.com> <CAPt1N1=UzXrsvHp2G_Nse8j8k7Uta3Bz7V-+2M9rdVeuo7Gn4A@mail.gmail.com>
In-Reply-To: <CAPt1N1=UzXrsvHp2G_Nse8j8k7Uta3Bz7V-+2M9rdVeuo7Gn4A@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.11.85.49]
Content-Type: multipart/alternative; boundary="_000_9142206A0C5BF24CB22755C8EC422E457A8F7E2FAZUS1EXMB03glob_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/dhcwg/xo8Capgrs02beCphvlkdtDeAYXk>
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] Adoption Call for draft-fang-dhc-dhcpv4-forcerenew-extensions-02 (Ends May 8, 2016)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 May 2016 19:05:44 -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

From: Ted Lemon [mailto:mellon@fugue.com]
Sent: Wednesday, May 04, 2016 2:26 PM
To: Mudric, Dusan (Dusan)
Cc: Tomek Mrugalski; dhcwg@ietf.org
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) <dmudric@avaya.com<mailto:dmudric@avaya.com>> 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:mellon@fugue.com<mailto:mellon@fugue.com>]
Sent: Wednesday, May 04, 2016 1:52 PM

To: Mudric, Dusan (Dusan)
Cc: Tomek Mrugalski; dhcwg@ietf.org<mailto:dhcwg@ietf.org>
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) <dmudric@avaya.com<mailto:dmudric@avaya.com>> wrote:
Is there a link  to that presentation? Are there problem statements for cloud deployments?

Thanks,
Dusan.

From: Ted Lemon [mailto:mellon@fugue.com<mailto:mellon@fugue.com>]
Sent: Wednesday, May 04, 2016 1:13 PM
To: Mudric, Dusan (Dusan)
Cc: Tomek Mrugalski; dhcwg@ietf.org<mailto:dhcwg@ietf.org>

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) <dmudric@avaya.com<mailto:dmudric@avaya.com>> 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:dhcwg-bounces@ietf.org<mailto:dhcwg-bounces@ietf.org>] On Behalf Of Tomek Mrugalski
Sent: Wednesday, May 04, 2016 12:42 PM
To: dhcwg@ietf.org<mailto:dhcwg@ietf.org>
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
dhcwg@ietf.org<mailto:dhcwg@ietf.org>
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
dhcwg@ietf.org<mailto:dhcwg@ietf.org>
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=>