Re: [v6ops] RFC7084

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

Return-Path: <otroan@employees.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 460671AE14E; Thu, 12 Dec 2013 02:02:25 -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 SgDKouPEk91M; Thu, 12 Dec 2013 02:02:24 -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 3A9101ACCDA; Thu, 12 Dec 2013 02:02:22 -0800 (PST)
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAKqIqVKQ/khL/2dsb2JhbABZgwe6QoEaFnSCJQEBBAF5EAtGVwaIDwbCRhePCAeDIYETBJAxmXaDKjs
X-IronPort-AV: E=Sophos; i="4.93,877,1378857600"; d="asc'?scan'208"; a="2060693"
Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 12 Dec 2013 10:02:14 +0000
Received: from dhcp-10-61-100-80.cisco.com (dhcp-10-61-100-80.cisco.com [10.61.100.80]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rBCA2949011748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 12 Dec 2013 10:02:10 GMT
Content-Type: multipart/signed; boundary="Apple-Mail=_C90C933E-47E5-4B49-AEE2-75A28B2CE743"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ole Troan <otroan@employees.org>
In-Reply-To: <73C046AB-7CC3-499D-B737-A9ECBD3963D4@nominum.com>
Date: Thu, 12 Dec 2013 11:02:10 +0100
Message-Id: <A639F21E-6004-4D23-AA50-A5D03BB26FDE@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>
To: Ted Lemon <ted.lemon@nominum.com>
X-Mailer: Apple Mail (2.1822)
Cc: 6man WG <ipv6@ietf.org>, "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] RFC7084
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Dec 2013 10:02:25 -0000

>> 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?

cheers,
Ole