Re: [v6ops] RFC7084

Alexandru Petrescu <alexandru.petrescu@gmail.com> Thu, 12 December 2013 12:17 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C235D1AE257; Thu, 12 Dec 2013 04:17:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.983
X-Spam-Level:
X-Spam-Status: No, score=-4.983 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, HELO_EQ_FR=0.35, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_HI=-5, SPF_SOFTFAIL=0.665] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnRs7_Sk1y9h; Thu, 12 Dec 2013 04:17:15 -0800 (PST)
Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.8]) by ietfa.amsl.com (Postfix) with ESMTP id BE6931AE256; Thu, 12 Dec 2013 04:17:14 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.3) with ESMTP id rBCCH3hP031693; Thu, 12 Dec 2013 13:17:03 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 1159C20503E; Thu, 12 Dec 2013 13:17:23 +0100 (CET)
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (Postfix) with ESMTP id 016D02012C5; Thu, 12 Dec 2013 13:17:23 +0100 (CET)
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 rBCCH3K7000927; Thu, 12 Dec 2013 13:17:03 +0100
Message-ID: <52A9A93F.8050804@gmail.com>
Date: Thu, 12 Dec 2013 13:17:03 +0100
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Owen DeLong <owen@delong.com>
Subject: Re: [v6ops] RFC7084
References: <96747494E3D74D41B20907035DB1E48DC7BB@MOPESMBX03.eu.thmulti.com> <2D09D61DDFA73D4C884805CC7865E611303B0269@GAALPA1MSGUSR9L.ITServices.sbc.com> <96747494E3D74D41B20907035DB1E48DCD72@MOPESMBX03.eu.thmulti.com> <alpine.DEB.2.02.1312100803370.24602@uplift.swm.pp.se> <F92E1B55-C74B-400C-B83E-6B50D175D121@steffann.nl> <7B4820C5-B562-4BE7-8C6A-CBCDABC39728@nominum.com> <A583EFC3-71BB-4962-875C-4AB775D13491@delong.com> <46BE373C-D476-4D83-B014-56B77FD3D67E@nominum.com> <39280481-09C5-41ED-B79E-99DBBD329F44@employees.org> <52A8343C.3040202@gmail.com> <CAAedzxq6ym-uZJQVC7JTMgKnETpGiNt3JCmkJeGW2MVnw+sixA@mail.gmail.com> <52A83C92.4020204@gmail.com> <A1A3DD00-96D8-4D73-B5F1-1CA705196689@delong.com>
In-Reply-To: <A1A3DD00-96D8-4D73-B5F1-1CA705196689@delong.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 12:17:18 -0000

Le 11/12/2013 19:51, Owen DeLong a écrit :
>
> On Dec 11, 2013, at 2:21 AM, Alexandru Petrescu
> <alexandru.petrescu@gmail.com> wrote:
>
>> Le 11/12/2013 11:08, Erik Kline a écrit :
>>>> Am I the only to read this as maybe a hint towards necessity
>>>> of creation of a new flag akin to M/O but specific to IA_PD?
>>>> I.e. it would be allow a Router to see whether it may be able
>>>> to specifically request a Delegated Prefix even when it would
>>>> self-configure its address by other means than DHCP.
>>>
>>> I'm not sure I understand how's that materially different/better
>>> than a node just trying to request a PD if it wants one, and
>>> coping with the response (whatever it may be), like it does
>>> today.
>>
>> Well, as you suggest below, it may save some bytes on the wire,
>> i.e. would not send the expensive Solicit if the preceding RA said
>> no PD available.
>
> I hardly think that an RS packet could legitimately be called
> “expensive”.

Well, I meant DHCP Solicit, not RS.

The DHCP exchange would be 4 messages, not two, and spaced by
pre-programmed timers and repeats.

But yes, on today's fast and fat links with good DHCP implementations,
that may be negligible.

> It’s a relatively small multicast datagram.
>
>> I suppose this is the same reason of presence of other flags in the
>> RA, like the H (HMIPv6) and P (PMIPv6).
>
> As near as I can tell, those flags are for capabilities that are:
>
> 1.	unlikely to be present on the majority of networks 2.	would be
> much more difficult/expensive to negotiate without information in the
> RA.
>
> The P flag isn’t alone in the RA, it’s also accompanied by a MAP
> option in the RA that provides information about the MAP.

(should the RA provide the delegated prefix as well to compare favorably
to the PMIP example? but again this is the 'what if' branch, deviating
from the main CPE discussion)

Alex

>
> Owen
>
>
>