Roger Jorgensen wrote:
On Wed, 11 Jul 2007, Tony Hain wrote:
I have a few points on Paul's draft:
<snip>
Major complaint - aggregation
There needs to be at least a modest capability to aggregate. I
understand the aversion to having these show up in the DFZ, but if
5.1 were
really true that would not be an issue. The use case that needs to be
supported is for internal aggregation of private peering clusters.
Global
organizations have many external relationships, but typically have them
clustered in small groupings for logistics reasons. At the same time
they
don't necessarily want to carry the explicit routes for every
organization
throughout their internal network. If the ULA-C/G space has some modest
aggregation like sparse allocation of the RIR num block to allow
clustering
subsequent block to the same RIR and a suggestion for E-W-N-S regional
management within the RIR space, then it would be possible to
aggregate the
internal routes to these private peering clusters.
IF we assume and prepare the ground for aggregation, would that just
make it easier in the future for this type of addresses being leaked?
<snip>
which again give us some sort of aggregation... is this something we
want? (althought it would fit us, where I work, perfectly since we
would get almost all the space we need quite easy:-)
I would agree with Tony that aggregation of ULA-G space should be
allowed. I know there are many others who disagree, but IMO mutually
assured destruction isn't called for here. As long as we have an
expectation that routes will be filtered, and have the ability to easily
do so, I don't think it matters whether we have lots of non-aggregated
routes or fewer aggregated ones...
-Scott
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
