Re: draft-ietf-ipv6-ula-central-02.txt

[Brian E Carpenter <[e-mail]>]

On 2007-07-11 21:52, Scott Leibrand wrote:
> 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...

I'd also add a heretical comment: if they agggregate, it doesn't *matter*
if they leak. In fact, they *will* leak up to the point where they
hit a shorter filter. That's physics.

    Brian

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[e-mail]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------