Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec)

Russ White <russw@riw.us> Fri, 09 September 2011 16:20 UTC

Return-Path: <russw@riw.us>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D1321F86C1 for <sidr@ietfa.amsl.com>; Fri, 9 Sep 2011 09:20:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.855
X-Spam-Level:
X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 QS276M9d1D-1 for <sidr@ietfa.amsl.com>; Fri, 9 Sep 2011 09:20:13 -0700 (PDT)
Received: from ecbiz91.inmotionhosting.com (ecbiz91.inmotionhosting.com [173.205.124.250]) by ietfa.amsl.com (Postfix) with ESMTP id E589521F863E for <sidr@ietf.org>; Fri, 9 Sep 2011 09:20:12 -0700 (PDT)
Received: from cpe-065-190-157-197.nc.res.rr.com ([65.190.157.197] helo=[192.168.100.63]) by ecbiz91.inmotionhosting.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <russw@riw.us>) id 1R23qB-0001BC-8j; Fri, 09 Sep 2011 12:22:07 -0400
Message-ID: <4E6A3D30.9030605@riw.us>
Date: Fri, 09 Sep 2011 12:22:08 -0400
From: Russ White <russw@riw.us>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0) Gecko/20110812 Thunderbird/6.0
MIME-Version: 1.0
To: Randy Bush <randy@psg.com>
References: <A37CADA4-F16D-4C01-8D9C-D01001C4EFE4@tcb.net> <21C19DA8-7BF3-4832-8C13-C9A45FE026FB@algebras.org> <87D9E106-2A37-4E1E-8C69-7084C199A3FE@tcb.net> <331AEFBD-6AE5-469E-A11E-E672DC61DCDC@pobox.com> <B92913D1-AB82-4D9F-B8A9-F8F4F99713D6@tcb.net> <p06240803ca685bff5443@[128.89.89.43]> <D6D12861-412E-4A65-B626-B627449981B8@tcb.net> <34E4F50CAFA10349A41E0756550084FB0C2ED5A4@PRVPEXVS04.corp.twcable.com> <7B321CF0-ABE6-4FCD-B755-8099BB63399A@rob.sh> <5E9BE75F-C0A6-4B48-B15F-7E0B80EFE981@ericsson.com> <m2ipp4qxs5.wl%randy@psg.com> <34E4F50CAFA10349A41E0756550084FB0E0D5BDC@PRVPEXVS04.corp.twcable.com> <D4059E53-6EEC-4F66-9E1E-B96675182F22@rob.sh> <m2wrdhvjpe.wl%randy@psg.com> <4E6A2CD0.1010305@riw.us> <m2pqj9vgc8.wl%randy@psg.com>
In-Reply-To: <m2pqj9vgc8.wl%randy@psg.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - ecbiz91.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - riw.us
Cc: sidr@ietf.org
Subject: Re: [sidr] BGPSec scaling (was RE: beacons and bgpsec)
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sidr>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Sep 2011 16:20:13 -0000

On 9/9/2011 12:19 PM, Randy Bush wrote:
>>>     as a vendor friend says, if ipv6 deploys, insha allah, we're gonna
>>>     be upgrading those routers to do real v6 forwarding.  if it does not
>>>     deploy, you will be deploying massively bigger boxes to nat your ass
>>>     into hell.
>>
>> There are two possible results, it seems to me:
>>
>> 1. The cost of deploying IPv6 will "bury" the cost of doing BGPsec, so
>> that BGPsec essentially becomes "free" in the IPv6 upgrade.
>>
>> 2. The cost of deploying BGPsec will be significant enough that it can't
>> be "buried," in any other costs.
>>
>> The question is --which is true?
> 
> as i have no data, any guess i make would be bullshit, would it not?

Does anyone have the data needed to answer which is true? My guess is
based on the cost of hardware in general --even small hardware costs
don't normally end up being "swamped"-- and the cost of network
convergence times, etc.

Using different assumptions, you can come to different conclusions. I
don't know how you can build a study that would tell you which set of
assumptions is "correct."

OTOH, it would be interesting to try.

Russ