Subject: Re: [RADIR] draft text for: 4.6 Dual Stack Pressure on the Routing Table

From: "John G. Scudder" <[email-masked]>
Date: Tue, 3 Jul 2007 13:57:47 -0400

A few nits:

s/100K routes per year/100 routes per year/ ?

I think most (all?) places where you use "routing table", "forwarding  
table" would be more correct.

s/predict/project/.  IMO.  ("Predict" implies, to me, a higher degree  
of certainty than I think there really is.  Maybe "guess." :-)

s/the future growth is unbounded/the potential for future growth is  
unbounded/

Overall I think the text is fine though it could probably be edited  
down to something shorter without losing the gist.  I may have a bit  
of time to take a stab at that later this week.

--John

_______________________________________________
RADIR mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/radir

---

From: Thomas Narten <[email-masked]>
Date: Mon, 16 Jul 2007 15:09:46 -0400

Hi Jason.

> Attached is some strawman text for section 4.6 talking about the impact of
> IPv4 / IPv6 dual stack on the routing system.  The numbers are a bit
> dated (03/07), and I hope to run a new batch early next week, but wanted
> to get some text out to see if this is what we were looking for.

> It is a bit long, and not sure if you want actual number here or not.

Reading through the text, I have a number of thoughts. First, there is
good stuff here and it needs to be captured somewhere/somehow. But
it's also long -- longer than ideal for the problem statement, and it
contains a bunch of numbers (and assumptions) that are going to change
over time and for which there is a fair amount of uncertainty. So I
worry it's too much detail for the main point the section should make.

IMO, what we want to capture is that with IPv6 deployment, the number
of routes will increase just due to dual-stack, and that number is
significant. But I think it is OK to not try to project the figures
too much (or put that in an appendix). Actually, I'd like to see
another document go into more detail about the actual growth rate
based on observable data with projections and analysis done
there. There are a lot of interesting questions that could be asked
that are worth going into. There is a lot of work to be done here.

What I think would be better for this document is to summarize the
problem, maybe have a short analysis (in the appendix, if needed) and
just make a point that that the IPv6 routes will be a minimum of the
number of ASNs, but will likely be higher (perhaps bring in the
results of just looking at the IPv4 table today, what could be
aggregated and what are more specifics) to come up with a rough factor
of 1/2 of the current IPv4 table, and say that this is a very rough
estimate and leave it at that.

The main point should be that with dual stack, we'll get more routes,
and it won't be just a minimum number based on ASNs. And many of the
pressures on IPv4 deaggregation will apply just as much to the IPv6
tables.

Thoughts?

> Also, this isn't exactly a "pressure to de-aggregate" so maybe we could
> rename section 4 to "pressures on the number of prefixes in the routing
> system"  

Or rename the section to "pressures increasing size of the routing
table?"

Thomas