Subject: [RADIR] Review of draft-narten-radir-problem-statement-01

From: Eric Rescorla <[email-masked]>
Date: Mon, 03 Dec 2007 15:50:54 -0800

[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
[email-masked]
https://www1.ietf.org/mailman/listinfo/radir