[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: draft-savola-multi6-asn-pi-01.txt



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>>> I guess that first we should agree that really big sites won't use
>>> multiaddressing and that they should obtain their own PI block.
>>> Then we need to define the criteria to identify big sites
>>> A finally then decide which addresses we should give them
>
>>> IMHO, the first decision concerns the IETF
>>> I am not so sure about the second and the third point, perhaps this
>>> should concern the rirs, more than the ietf?
>
>> Agreed. We could make our lives very easy and just say that the 
>> current
>> filtering policy is up to the RIRs to handle. By that giving them also
>> one of the other keys to the multihoming problem - just break
>> aggregation. IMHO this is where we are today. But as most sites
>> actually do filter on allocation boundaries, we don't have an issue.
>
> I am profoundly unsatisfied with the way the RIRs operate in this 
> regard. For instance, they set a policy and then don't stick to it 
> (see my rant at http://www.ipv4.bgpexpert.com/archive2003q4.php never 
> mind the "ipv4" in the URL, I'm on the road and for some reason 
> contacting my site using a hostname that has an IPv6 address doesn't 
> work too well). Also, since anyone can participate in the policy 
> decision making process, they're pretty much a special interest group 
> in this regard and if there is enough pressure to make something 
> happen, it will happen, regardless of whether it's a good idea.

Well, there are a lot of things you can say about the RIR policies, but 
let's take that to some other mailinglist :)

>
> If we want to break aggregation in a way that doesn't break 
> scalability then I think we need to put out an RFC that tells people 
> how to do it, so that it's actually usable (no point in doing this if 
> network operators filter) and scalable. I think it can be done but 
> Pekka's draft isn't the way.


I think that the issue of breaking aggregation will have to be part of 
the general architectural discussion. Just like any other proposal.

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQDnf1qarNKXTPFCVEQLSIACfX7eIIUgFFIFdDsWCXMXQOPyJ5HYAoMDm
fMkIfUBcQSqP2wQ90WNjQ/bX
=X8EU
-----END PGP SIGNATURE-----