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 17:43 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 C603811E80A3 for <dhcwg@ietfa.amsl.com>; Tue, 4 Sep 2012 10:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.299
X-Spam-Level:
X-Spam-Status: No, score=-106.299 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 ApkVfRadLBKZ for <dhcwg@ietfa.amsl.com>; Tue, 4 Sep 2012 10:43:48 -0700 (PDT)
Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by ietfa.amsl.com (Postfix) with ESMTP id B173511E809A for <dhcwg@ietf.org>; Tue, 4 Sep 2012 10:43:48 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKUEY91M4djmULuguIW+ZGeoyJQCKMfGa0@postini.com; Tue, 04 Sep 2012 10:43:48 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 BAE671B829F for <dhcwg@ietf.org>; Tue, 4 Sep 2012 10:43:47 -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 A53DB19005C; Tue, 4 Sep 2012 10:43:47 -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 10:43:47 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Ole Trøan <otroan@employees.org>
Thread-Topic: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08
Thread-Index: AQHNilxkzqWc/Q9DJ0mcHtn1PhlGPpd6qseAgAArj4CAABP1gA==
Date: Tue, 04 Sep 2012 17:43:47 +0000
Message-ID: <FDF07965-FE45-4A36-8563-EFD748351A39@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> <6C1B27BB-3FBD-4046-9923-0FE6080D8AEC@nominum.com> <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org>
In-Reply-To: <22044EFB-C429-4CF9-A2BB-23EFE1331A24@employees.org>
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: text/plain; charset="Windows-1252"
Content-ID: <5A79DAE5317A6449AF7B8EACFD0B3B22@nominum.com>
Content-Transfer-Encoding: quoted-printable
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 17:43:55 -0000

On Sep 4, 2012, at 12:32 PM, Ole Trøan <otroan@employees.org> wrote:
> fate sharing of what? the client functions independently of whatever aggregate route there is for a whole block of subscribers. this just adds another cog in the machinery that may fail.

Fate sharing in the sense that the DHCP server is best able to know from what aggregate prefix prefixes for clients on a particular router will be allocated, and the DHCP packet is the way these prefixes get allocated to the client.   So we can be sure that if the network is working at all, it will be working completely.

> this does not solve the DHCPv6 PD problem of route injection. a route needs to be installed per client, and snooping is still needed for that. this proposal _only_ solves the problem of installing an aggregate route for multiple PD RRs into a PE/relay. this is most typically done with static configuration today.

It solves half the problem: configuring the route that the router advertises.   You are correct that it doesn't solve the other half—figuring out where to send packets downstream.   But actually, snooping the DHCP packet is a perfectly good solution for this problem; what is lacking is a standard that says how it's done. 

What snooping is _not_ good for is figuring out what route to advertise upstream.   To say that the upstream route is currently done with static configuration is synonymous with saying that the problem is currently unsolved.

v2.23.0 | Report a Bug | By Email