[RADIR] Review of draft-narten-radir-problem-statement-01
Eric Rescorla <ekr@networkresonance.com> Tue, 04 December 2007 13:14 UTC
Return-path: <radir-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzXbw-0005I3-Aj; Tue, 04 Dec 2007 08:14:52 -0500
Received: from radir by megatron.ietf.org with local (Exim 4.43) id 1IzL99-0000NL-K7 for radir-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 18:56:19 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzL99-0000LJ-6e; Mon, 03 Dec 2007 18:56:19 -0500
Received: from dhcp-11b6.ietf70.org ([130.129.17.182] helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzL98-0003Qf-EY; Mon, 03 Dec 2007 18:56:19 -0500
Received: from delta.rtfm.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 6390533CA0; Mon, 3 Dec 2007 15:50:55 -0800 (PST)
Date: Mon, 03 Dec 2007 15:50:54 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: narten@us.ibm.com, radir@ietf.org, iab@ietf.org, iesg@ietf.org
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20071203235055.6390533CA0@delta.rtfm.com>
X-Spam-Score: 0.8 (/)
X-Scan-Signature: 386e0819b1192672467565a524848168
X-Mailman-Approved-At: Tue, 04 Dec 2007 08:14:51 -0500
Cc:
Subject: [RADIR] Review of draft-narten-radir-problem-statement-01
X-BeenThere: radir@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Directorate <radir.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/radir>, <mailto:radir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/radir>
List-Post: <mailto:radir@ietf.org>
List-Help: <mailto:radir-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/radir>, <mailto:radir-request@ietf.org?subject=subscribe>
Errors-To: radir-bounces@ietf.org
[IAB, this is a retransmit of my previous review.] -Ekr $Id: draft-narten-radir-problem-statement-01-rev.txt,v 1.1 2007/11/28 21:04:07 ekr Exp $ This document was produced by the Routing and Addressing Directorate in an attempt to describe what "the problem" is in routing and addressing. However, after reading this document, I'm still confused. As I understand it, the high level argument looks like this: - The consumption of a number of routing-related resources is expanding + DFZ table size + Routing update volume - This implies that ISPs have to buy new gear - Maybe that new gear can't be produced - There is no incentive structure - We should design a new set of routing mechanisms that behave differently in each respect. This document seems to me to leave major unanswered questions about each of these points. 1. The rate of growth S 3. asserts that the rate of growth is "superlinear". This is pretty cautious phrasing, I imagine as a result of pushback on previous characterizations of the rate of growth as exponential. In any case, I don't see that "superlinear" is a problem at all, given that hardware capacity has historically increased at a rate that looks a lot more like exponential. The amount of space consumed by my mail on disk is increasing superlinearly (I archive forever), but I don't worry about it because disk space is getting cheap so much faster. So, a system which is growing slower than the pace of new technology seems fine. One of the major issues in this discussion has always been the relative magnitude of these growth rates and I don't see this document providing any evidence that this constitutes a problem. 2. ISP gear purchases S 3.2. reads: One aspect of planning concerns the assumptions made about the expected usable lifetime of purchased equipment. Businesses typically expect that once deployed, equipment can remain in use for some projected amount of time (e.g., 3-5 years). Upgrading equipment earlier than planned is more easily justified (as an unplanned expense) when a new business opportunity is enabled as a result of an upgrade. I don't think this argument is quite correct. At any given time T, you buy enough capacity that given the projected rate of growth that capacity will match consumption at time T + dT, at which point you need to buy new gear. The only time in which this induces unplanned purchases is if the rate of growth doesn't match expectations. Even then, as long as the net rate of capacity is >= the net rate of consumption growth, you can have any replacement cycle you want merely by buying more up front. The only exception here is when you're buying the absolute most capable gear. But that's presumably a problem the vendors could solve by throwing more hardware at the gear up front unless they're exactly at the technical frontier. 3. The technical frontier I've heard claims that we're going to outstrip the ability to produce new capacity. I've also heard claims that we're not. I suppose this makes it "uncertain", but since this is the crux of the issue, I don't see how a draft that doesn't actually answer the question is that useful. 4. Incentive structure OK, this I mostly agree with. Routing advertisements have negative externalities. But why do you not propose fixing this? 5. The way forward Even if we stipulate 1-3, why does that mean a new routing protocol? Why aren't we recommending something that instead rebalances the costs towards the parties which are consuming prefixes. I can think of a number of alternatives (SHIM6, charging for prefix advertisement, etc.) Despite the fact that I don't agree with much of this document, I don't have a problem with it being published as Thomas's opinion, the RADIR's opinion, whatever, so long as it's not labelled the IETF or IAB opinion. _______________________________________________ RADIR mailing list RADIR@ietf.org https://www1.ietf.org/mailman/listinfo/radir
- [RADIR] Review of draft-narten-radir-problem-stat… Eric Rescorla