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

Leaf yeh <leaf.y.yeh@huawei.com> Thu, 06 September 2012 03:00 UTC

Return-Path: <leaf.y.yeh@huawei.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 7F9CF21F84BF for <dhcwg@ietfa.amsl.com>; Wed, 5 Sep 2012 20:00:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.849
X-Spam-Level:
X-Spam-Status: No, score=-5.849 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, J_CHICKENPOX_22=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 eO6sjUrtnS0u for <dhcwg@ietfa.amsl.com>; Wed, 5 Sep 2012 20:00:47 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6BBF321F854D for <dhcwg@ietf.org>; Wed, 5 Sep 2012 20:00:46 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AKJ94793; Thu, 06 Sep 2012 03:00:44 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Sep 2012 03:59:51 +0100
Received: from SZXEML437-HUB.china.huawei.com (10.72.61.72) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 6 Sep 2012 04:00:39 +0100
Received: from SZXEML510-MBS.china.huawei.com ([169.254.8.119]) by szxeml437-hub.china.huawei.com ([10.72.61.72]) with mapi id 14.01.0323.003; Thu, 6 Sep 2012 11:00:32 +0800
From: Leaf yeh <leaf.y.yeh@huawei.com>
To: Ole Trøan <otroan@employees.org>, Ted Lemon <Ted.Lemon@nominum.com>
Thread-Topic: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08
Thread-Index: AQHNiz3JybEem5ZQYkac9Lq+3sR22Zd8h9xw
Date: Thu, 06 Sep 2012 03:00:32 +0000
Message-ID: <E1CE3E6E6D4E1C438B0ADC9FFFA345EA3C46A3A3@SZXEML510-MBS.china.huawei.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> <FDF07965-FE45-4A36-8563-EFD748351A39@nominum.com> <0CFEF31D-4A01-42A7-89B7-69BDBB41E9C8@employees.org> <6069AF94-1587-496D-BE15-5A9B6892E9F6@nominum.com> <FC830748-7F37-4AAB-A843-B75576B27B84@employees.org>
In-Reply-To: <FC830748-7F37-4AAB-A843-B75576B27B84@employees.org>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.66.83.152]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dhcwg@ietf.org WG" <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: Thu, 06 Sep 2012 03:00:49 -0000

Ole - I might be missing something here. I don't understand how the aggregate route for a set of delegated prefixes is dynamic. when and how could all subscribers within a aggregate move?

It is my duty to make you love it. :-)

General Idea Clarification on the draft (OPTION_PREFIX_POOL):  The draft defined the 'Status' of the PD prefix pool in Section 4, which maintained on the server (and the relay). It has 2 codes now, 'Active' or 'Released', which can be derived from the leases of delegated subscriber prefixes, or be set by the administration of server. The 'Status' in the OPTION_PREFIX_POOL received by the relay is used for the addition or removal the aggregation route on the PE router (acting as the relay).


Best Regards,
Leaf



-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Ole Tr?an
Sent: Wednesday, September 05, 2012 4:07 PM
To: Ted Lemon
Cc: dhcwg@ietf.org WG
Subject: Re: [dhcwg] Call for Adoption: draft-yeh-dhc-dhcpv6-prefix-pool-opt-08

Ted,

>> I look at it differently. you are adding more complexity on functions that are not in the data path. in my book that isn't fate sharing.
> 
> How is this not on the data path?

the DHCP server is not on the data path. unless one follows the model described in 3633 where the DHCP server is on the PE router.

[...]

>> this is like saying that configuring OSPF on a router is a unsolved problem, just because it isn't done with DHCP. ;-)
> 
> No, if OSPF is how these routers are being configured, that's not what I think of as static configuration.   Is that in fact the case?   It's my understanding that there is no clean dynamic configuration mechanism that ties back to the address allocation system (that is, to DHCP). 

I might be missing something here. I don't understand how the aggregate route for a set of delegated prefixes is dynamic. when and how could all subscribers within a aggregate move?

> It seems to me that what we are talking about here is exactly analogous to what's done today in IPv4 with DHCP snooping and DHCP leasequery, both of which seem to be good solutions that are widely deployed and work well for network providers.   If there's a better way, I'm all ears, but when I asked in the routing area, I got some pretty vague answers that sounded a lot like "it's configured statically."

hmm, I didn't think the IPv4 aggregate route was deduced or configured from DHCPv4 either. the deployments I'm aware of, the PE is always configured outside of DHCP with the IPv4 subnets / aggregate routes. what's the analogy?

cheers,
Ole