Re: [v6ops] RFC7084

Ole Troan <otroan@employees.org> Thu, 12 December 2013 11:15 UTC

Return-Path: <otroan@employees.org>
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 226FF1AE08D; Thu, 12 Dec 2013 03:15:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no
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 XhsIZxLr5tZc; Thu, 12 Dec 2013 03:15:38 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6B25C1AD937; Thu, 12 Dec 2013 03:15:38 -0800 (PST)
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFACaaqVKQ/khN/2dsb2JhbABZgwe6QoEcFnSCJgEFeRALRlcGiBXCXhePCAeDIYETBJAxmXaDKjs
X-IronPort-AV: E=Sophos; i="4.93,877,1378857600"; d="asc'?scan'208"; a="2070484"
Received: from ams-core-4.cisco.com ([144.254.72.77]) by aer-iport-1.cisco.com with ESMTP; 12 Dec 2013 11:15:29 +0000
Received: from dhcp-10-61-100-80.cisco.com (dhcp-10-61-100-80.cisco.com [10.61.100.80]) by ams-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rBCBFPkc013390 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Dec 2013 11:15:25 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_F11CA7DD-494B-4BA5-8988-3D10A84DA625"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
Subject: Re: [v6ops] RFC7084
From: Ole Troan <otroan@employees.org>
In-Reply-To: <52A99942.5030000@gmail.com>
Date: Thu, 12 Dec 2013 12:15:24 +0100
Message-Id: <5F250E9B-66B1-4858-9DBC-60CEB50AFE54@employees.org>
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> <73C046AB-7CC3-499D-B737-A9ECBD3963D4@nominum.com> <A639F21E-6004-4D23-AA50-A5D03BB26FDE@employees.org> <52A99942.5030000@gmail.com>
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
X-Mailer: Apple Mail (2.1822)
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, 6man WG <ipv6@ietf.org>, Ted Lemon <ted.lemon@nominum.com>
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 11:15:40 -0000

Alexandru,

>>>> 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.
>>> 
>>> The usual concern is that a bazillion devices all requesting PDs
>>> every so often adds up to a lot of traffic.   But since the
>>> existing spec doesn't forbid this, we're stuck with it.
>> 
>> then you're understanding of "usual" is different from mine. :-) as
>> far as I know this can only happen in very specific circumstances
>> during transition.
>> 
>> we should be more concerned about this idea of using one protocol to
>> provision another. in this case ND to configure DHCP. is that a good
>> design principle to follow?
> 
> PRobably not.  Stated as such it would be too limiting (ND to help
> running _just_ DHCP).
> 
> Maybe Radius as well.  The RA would just say that some means is
> available to offer a delegated prefix, w/o saying which, without saying whether it is stateful or stateless, secure or insecure, etc.

for what purpose?
would the CE behave any differently if the network advertised that PD was available or not?

cheers,
Ole