IETF Logo Mail Archive

Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

Ted Lemon <Ted.Lemon@nominum.com> Tue, 04 September 2012 13:56 UTC

Return-Path: <Ted.Lemon@nominum.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 D490221F850C for <dhcwg@ietfa.amsl.com>; Tue, 4 Sep 2012 06:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.598
X-Spam-Level:
X-Spam-Status: No, score=-106.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zdM0YdH4jmaq for <dhcwg@ietfa.amsl.com>; Tue, 4 Sep 2012 06:56:28 -0700 (PDT)
Received: from exprod7og102.obsmtp.com (exprod7og102.obsmtp.com [64.18.2.157]) by ietfa.amsl.com (Postfix) with ESMTP id CAC8621F854A for <dhcwg@ietf.org>; Tue, 4 Sep 2012 06:56:27 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob102.postini.com ([64.18.6.12]) with SMTP ID DSNKUEYIi9uvuGZN7IhG6bVivGHea0X1hB2s@postini.com; Tue, 04 Sep 2012 06:56:27 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id A0A8A1B80B8 for <dhcwg@ietf.org>; Tue, 4 Sep 2012 06:56:26 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 95EDB19005C; Tue, 4 Sep 2012 06:56:26 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Tue, 4 Sep 2012 06:56:26 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" <shrinivas_ashok.joshi@alcatel-lucent.com>
Thread-Topic: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08
Thread-Index: AQHNilxkzqWc/Q9DJ0mcHtn1PhlGPpd6qseA
Date: Tue, 04 Sep 2012 13:56:26 +0000
Message-ID: <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com>
References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com> <6B6C7CCC-0971-4CD1-BC2F-849F6BDC1863@employees.org> <5044C350.4010403@gmail.com> <E666D4CA7557D04DB6B9B2BA6DC28F3D285C2A36F8@INBANSXCHMBSA3.in.alcatel-lucent.com>
In-Reply-To: <E666D4CA7557D04DB6B9B2BA6DC28F3D285C2A36F8@INBANSXCHMBSA3.in.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: multipart/alternative; boundary="_000_6C1B27BB3FBD404699230FE6080D8AECnominumcom_"
MIME-Version: 1.0
Cc: "dhcwg@ietf.org" <dhcwg@ietf.org>
Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 04 Sep 2012 13:56:30 -0000

On Sep 4, 2012, at 1:15 AM, "JOSHI, SHRINIVAS ASHOK (SHRINIVAS ASHOK)" <shrinivas_ashok.joshi@alcatel-lucent.com<mailto:shrinivas_ashok.joshi@alcatel-lucent.com>> wrote:
This would not have the overhead per transaction and also the handling at the relay would be much elegant and simpler.
Current draft requires relay to implement bulk lease query and additional processing per relayed PD request.

The overhead per transaction here is a bit of a red herring—we're talking about thirteen bytes, if I count correctly.

Furthermore, the working group already went down the path of separating out the transactions a couple of years ago, and determined that there were synchronization problems; that work was eventually dropped for lack of interest.

The problem remains unsolved; this is actually a pretty good solution, because it involves fate sharing, with a netconf solution wouldn't have, and uses an established communications path, which netconf/yang doesn't offer.

This is definitely better than the solution vendors are currently offering, which is to simply sniff the prefixes from DHCP messages to the client.   With my working group chair hat off, I'm in favor of doing this work precisely because it solves the problem neatly, and no better solution has ever been presented of which I'm aware.

v2.23.0 | Report a Bug | By Email