Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?

"Leaf Yeh" <leaf.yeh.sdo@gmail.com> Tue, 27 August 2013 03:54 UTC

Return-Path: <leaf.yeh.sdo@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 23A6C11E8133 for <dhcwg@ietfa.amsl.com>; Mon, 26 Aug 2013 20:54:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E00g+rwHr3iq for <dhcwg@ietfa.amsl.com>; Mon, 26 Aug 2013 20:54:27 -0700 (PDT)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com [IPv6:2607:f8b0:400e:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 2420111E813F for <dhcwg@ietf.org>; Mon, 26 Aug 2013 20:54:25 -0700 (PDT)
Received: by mail-pa0-f50.google.com with SMTP id fb10so4269798pad.37 for <dhcwg@ietf.org>; Mon, 26 Aug 2013 20:54:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:thread-index :content-language; bh=EozGZ6wJ1B5ad++pS4tpZEzJ1TJIXbPP9kF+Zsf87dw=; b=wyakNLqDIyly5ANSpPfIZQaG2Ff2nQXKhaexQCweX/TMC4pOOCRTQlLa+zyd50ba5L FQdAasLbbzODeE4OOykXlKwnNIAQgrlFcTolzrz5CKwNR42pmXtyyFqOFKVFjt3RbZ1V SbhqFHKtt+8pdaRbO4Nz0JRt630khEuRNdqgubFqh0tG7Q6xl9/PDJkGBiltFpxetqRn sauBaUN87faQX/4x4SVE+E8TY/vDK+d+s0Ft9Ma977tqltvpWvuGNik0KyWrIeIzUlQg CYBBpArr6fo1bdzKP7NsD65IFYtn29tzkgcp7zWaYPljfb9iHT4cCw1FIsKXERz8G6Ba 9lLg==
X-Received: by 10.68.169.161 with SMTP id af1mr18958292pbc.22.1377575658867; Mon, 26 Aug 2013 20:54:18 -0700 (PDT)
Received: from PC ([114.248.227.178]) by mx.google.com with ESMTPSA id yg1sm21613623pbb.1.1969.12.31.16.00.00 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 26 Aug 2013 20:54:18 -0700 (PDT)
From: "Leaf Yeh" <leaf.yeh.sdo@gmail.com>
To: "'Ralph Droms'" <rdroms.ietf@gmail.com>, "'Bernie Volz \(volz\)'" <volz@cisco.com>
References: <52123110.10205@gmail.com> <94C682931C08B048B7A8645303FDC9F36EEDD8B410@PUEXCB1B.nanterre.francetelecom.fr> <5214BF85.8020509@gmail.com> <8166FEF1-0991-4BDF-A35C-6D6E922CF0DD@gmail.com> <489D13FBFA9B3E41812EA89F188F018E186A6607@xmb-rcd-x04.cisco.com> <2EEEA569-D28B-4EE7-806A-E74616519D20@gmail.com>
In-Reply-To: <2EEEA569-D28B-4EE7-806A-E74616519D20@gmail.com>
Date: Tue, 27 Aug 2013 11:54:06 +0800
Message-ID: <521c22ea.41a3440a.1475.4d9e@mx.google.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac6igdunGLX91S+jRsSEGqk84ddDuwAUpbEg
Content-Language: zh-cn
Cc: dhcwg@ietf.org, 'Alexandru Petrescu' <alexandru.petrescu@gmail.com>
Subject: Re: [dhcwg] Anyone interested in continuing draft-ietf-dhc-dhcpv6-prefix-pool-opt?
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, 27 Aug 2013 03:54:32 -0000

[Ralph] I think it would be much cleaner to include the operation code in
the prefix-pool-opt itself.  

The operation code in the OPTION_PREFIX_POOL defined in this draft sounds in
the 'status' field.


[Ralph] If I recall correctly from the discussion of agentopt-delegate,
there were questions about the reliability of piggy-backing: suppose
messages are delivered out-of-order or delivered through different relay
agents?

I guess the reliability of the DHCPv6 option (eg. OPTION_ORO,
OPTION_PREFIX_POOL) sounds the same as that of DHCPv6 (PD) message


[Ralph] Someone else pointed out that there are many other configuration
knobs that need to be set in the relay-router. Why use DHCP just for the
prefix routing and not the other configuration?

Just because this part could be dynamic.


Best Regards,
Leaf



-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of
Ralph Droms
Sent: Tuesday, August 27, 2013 1:30 AM
To: Bernie Volz (volz)
Cc: dhcwg@ietf.org WG; Alexandru Petrescu
Subject: Re: [dhcwg] Anyone interested in continuing
draft-ietf-dhc-dhcpv6-prefix-pool-opt?

Bernie - thanks for the clarifications.

I'm curious about the demand for this option.  Is there explicit demand from
a group of SPs that want to use this option, or is being defined in
speculation of SP demand?  Is it really the case that the SP may dynamically
change the prefix delegation architecture in a dynamic way that requires
this specific automated configuration?

In my opinion, piggy-backing the prefix-pool option on client-server
communication is not appropriate.  As you point out, piggy-backing may not
provide relay-router/server communication at the time it is needed.  Also,
if I read the draft correctly and the relay-router snoops the server->client
message to determine how to interpret the prefix-pool-opt, I think it would
be much cleaner to include the operation code in the prefix-pool-opt itself.
If I recall correctly from the discussion of agentopt-delegate, there were
questions about the reliability of piggy-backing: suppose messages are
delivered out-of-order or delivered through different relay agents?

Someone else pointed out that there are many other configuration knobs that
need to be set in the relay-router.  Why use DHCP just for the prefix
routing and not the other configuration?

Has the alternative of a routing protocol been considered?

- Ralph

On Aug 22, 2013, at 6:12 AM 8/22/13, Bernie Volz (volz) <volz@cisco.com>
wrote:

> Ralph:
> 
> Thanks for bringing up that old draft! There were issues here that caused
this work to be abandoned.
> 
> And, yes and no regarding draft-ietf-dhc-dhcpv6-agentopt-delegate. I 
> think one difference in the prefix-pool is that this is more to handle 
> the case where the relay (router) is told to inject X/48 into the 
> routing instead of Y/64 or Y/60 that might be going to the client. 
> (This it to avoid having to inject lots of /64 or /60 routes when many 
> clients are 'connected via the router'.)
> 
> Agentop could have been used to do that, but I'm not sure that was
explicitly discussed or covered (and I didn't check the draft).
> 
> I did like agentop better than this proposal in one respect - and that is
its use of lifetimes for the prefix. Prefix-pool's uses a flag is a terrible
idea (IMHO) since there is nothing to guarantee communication on which to
piggyback the request to remove the pool. A lifetime covers that as it
causes the entry to expire on its own. And, 0 lifetimes can be used to
remove 'now'. But that's more of a minor issue as to whether the entire work
is appropriate.
> 
> Cable CMTS devices have been snooping address and PD assignments for a
long time now and rather successfully. I suspect that the 'prefix pool'
issue there is handled by static configuration on the CMTS.
> 
> - Bernie
> 
> -----Original Message-----
> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf 
> Of Ralph Droms
> Sent: Thursday, August 22, 2013 8:48 AM
> To: Alexandru Petrescu
> Cc: dhcwg@ietf.org WG
> Subject: Re: [dhcwg] Anyone interested in continuing
draft-ietf-dhc-dhcpv6-prefix-pool-opt?
> 
> 
> On Aug 21, 2013, at 9:24 AM 8/21/13, Alexandru Petrescu
<alexandru.petrescu@gmail.com> wrote:
> 
>> Hi,
>> 
>> One point I think is essential is the installment of routes in the 
>> DHCP Relay upon Prefix Assignment.
>> 
>> The base DHCPv6 Prefix Delegation RFC does not stipulate that DHCP 
>> must install a route in the DHCP Relay upon delegation.
>> 
>> This draft seems to at least assume it, and to describe much more 
>> about
>> it: how various parts of assigned prefixes are aggregated and
communicated.
>> 
>> I support it.
> 
> After a quick read, draft-ietf-dhc-dhcpv6-agentopt-delegate seems to have
been aimed at the same problem.  If I have that right, it might be
instructive to review the dhc WG mailing list discussion that lead to the
abandonment of draft-ietf-dhc-dhcpv6-agentopt-delegate.
> 
> - Ralph
> 
>> 
>> Alex
>> 
>> Le 21/08/2013 14:41, mohamed.boucadair@orange.com a écrit :
>>> Hi Tomek,
>>> 
>>> I do still think draft-ietf-dhc-dhcpv6-prefix-pool-opt documents a 
>>> useful feature in order to have more automation and also control 
>>> routes aggregation instead of relying on proprietary behaviors of 
>>> each implementation. Of course, part of these objectives can be 
>>> achieved if routes are installed manually or use an out of band 
>>> mechanism to enforce routing aggregation policies. Still, the 
>>> proposal in draft-ietf-dhc-dhcpv6-prefix-pool-opt is superior 
>>> because the DHCP server has the knowledge of the prefix assignments; 
>>> and therefore routes can be triggered with dhcpv6 .
>>> 
>>> A way to progress with this document is to target the Experimental 
>>> track. Based on the experience that will be gained in real 
>>> deployments, the status can be revisited if required.
>>> 
>>> Cheers, Med
>>> 
>>>> -----Message d'origine----- De : dhcwg-bounces@ietf.org 
>>>> [mailto:dhcwg-bounces@ietf.org] De la part de Tomek Mrugalski 
>>>> Envoyé
>>>> : lundi 19 août 2013 16:52 À : dhcwg Objet : [dhcwg] Anyone 
>>>> interested in continuing draft-ietf-dhc-dhcpv6- prefix-pool-opt?
>>>> 
>>>> During Berlin meeting chairs asked if there is still interest in 
>>>> the prefix-pool-option. There was nobody interested in the work in 
>>>> the room. The unanimous consensus in the room was to drop it. I 
>>>> just wanted to confirm that on the list.
>>>> 
>>>> If you are interested in this work, want to support it and 
>>>> participate in it, please let us know by replying to the mailing 
>>>> list. Otherwise we'll drop this work and mark that draft as a dead 
>>>> WG document.
>>>> 
>>>> Please respond within 2 weeks (until Sep. 2nd).
>>>> 
>>>> Bernie & Tomek _______________________________________________
>>>> dhcwg mailing list dhcwg@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dhcwg
>>> _______________________________________________ dhcwg mailing list 
>>> dhcwg@ietf.org https://www.ietf.org/mailman/listinfo/dhcwg
>>> 
>>> 
>> 
>> 
>> _______________________________________________
>> dhcwg mailing list
>> dhcwg@ietf.org
>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www.ietf.org/mailman/listinfo/dhcwg

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg