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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 07 September 2012 12:51 UTC

Return-Path: <alexandru.petrescu@gmail.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 F19D621F8790 for <dhcwg@ietfa.amsl.com>; Fri, 7 Sep 2012 05:51:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
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 vMJ0QlbfEAb2 for <dhcwg@ietfa.amsl.com>; Fri, 7 Sep 2012 05:51:59 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id C049A21F87B0 for <dhcwg@ietf.org>; Fri, 7 Sep 2012 05:51:58 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id q87CpvcG007481 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <dhcwg@ietf.org>; Fri, 7 Sep 2012 14:51:57 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id q87CpvLq021661 for <dhcwg@ietf.org>; Fri, 7 Sep 2012 14:51:57 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] (is010446-4.intra.cea.fr [10.8.33.116]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.2) with ESMTP id q87Cpu4h019429 for <dhcwg@ietf.org>; Fri, 7 Sep 2012 14:51:57 +0200
Message-ID: <5049EDEC.7000607@gmail.com>
Date: Fri, 07 Sep 2012 14:51:56 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120824 Thunderbird/15.0
MIME-Version: 1.0
To: dhcwg@ietf.org
References: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com>
In-Reply-To: <91484F36-D059-4D90-8BFE-60434864A579@nominum.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
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: Fri, 07 Sep 2012 12:52:00 -0000

I think it should be adopted because I like the idea to avoid numerous
dynamic specific routes presumably introduced by the use of Prefix
Delegation for autoconfiguring mobile routers on a large scale.

But I also think that some of the problem of too many specific routes in
the dynamic routing protocol generated by Relay could be avoided with
help from (1) a better address planning by a human and (2) less computer
intelligence at Relay.

To me it also depends on the willingness of authors to push forward and
of group members to help find consensus.

Let's see further,

Alex

Le 24/08/2012 17:32, Ted Lemon a écrit :
> The authors have proposed that the working group adopt the prefix
> pool option draft as a working group item.   We have engaged in some
> correspondence with participants in the Routing Area, and while some
> helpful advice was given, no objections were raised to going forward
> with the work, and it's a DHCP protocol extension, so it makes sense
> for it to happen in the DHC working group.
>
> The document proposes an extension to the DHCP protocol that allows
> the DHCP server to communicate prefixes to the provider edge router
> when doing prefix delegation, such that this router can advertise a
> route to an aggregate prefix, rather than to many individual
> prefixes, and so that this router does not have to perform ad-hoc
> prefix aggregation, which may produce less optimal results.
>
> If you think this work should be adopted by the working group,
> please reply to this message saying so.   If you think this work
> should not be adopted by the working group, please reply to this
> message saying so.   We will evaluate consensus on September 7.
>
> _______________________________________________ dhcwg mailing list
> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
>
>