Thank you for responding Thomas. I don't think what you propose is
sufficient. (More after your comments, for context.)
Thomas Narten wrote:
Hi Joel.
Thanks for the comments.
Thomas, one major and some minor comments on the document.
The discussion of IPv6 routing table size in section 4.6 seems
misleading. The discussion seems to have no component to represent the
present and increasing demand for PI addresses in order to support
multi-homing and ease of renumbering. If we do not have a routing
architecture and system which addresses those pressures, and if we do
not manage to keep in place an artificial barrier to such PI
assignments, the size of the tables will grow dramatically. Some
stimates place the expected number of multiohomed enterprises in the
ballpark of 10,000,000. That would represent a significant growth in
the control plane, the RIB, and the FIB.
This section was intended to simply point out that dual stack adds
even more routes, in the sense that one will need both IPv4 and IPv6
route to the same destination. That only further increases the overall
number of entries a router deals with.
It goes without saying (and looking back, the document doesn't say
this) that all the pressures that apply to IPv4 routing, apply pretty
much equally to IPv6.
Seems to me, that the best way to deal with that is to add a new
paragraph (perhaps in the introduction) that calls this out
explicitely. I.e., something like:
Most of this document does not distinguish between IPv4 and
IPv6. The overall routing archtecture for the two protocols is the
same. Consequently, most of the issues in this document apply
equally to IPv4 and IPv6. Any behavior that places pressure on IPv4
routing is likely to also exert the same pressure on IPv6.
Deployment of IPv6 will not lessen these pressures in most cases.
What you propose to add is good. But, the text in 4.6 as written claims
"It is possible to extrapolate what the size of the IPv6 routing table
would be if wide spread adoption of IPv6 occurred..." Unfortunately,
the extrapolation that then takes place assumes that the same factors
that currently constrain IPv4 sizes would constrain IPvb6 sizes, and
that seems extremely unlikely. Hence, this extrapolation is very
optimistic, and misleading to the reader.
Yours,
Joel
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
