Policy Statement on Address Space Allocations
Sean Doran smd at icp.net
Fri Jan 26 15:03:19 CET 1996
Jeff Young wrote: | say what you will about this policy, but someone (sean?) thought | long and hard about it's implications. i didn't like the abrupt | manner in which it was implemented, but it does take guts and it | is pretty elegant: Thanks, Jeff. Once again I shall repeat my apologies -- the original intent was to make sure the filters would break things on day one, rather than retroactively apply to the number of people whose route announcements had been leaked in by mistake. Despite the immediate retrospective thought that it was a cute way to avoid accusations of collusion among big providers, I did very much regret the work you folks and others had to do when this got dropped into place. OTOH, well, there had been several months' warning about the details... But still, sorry that it wasn't as smooth as it could have been if there hadn't been a flaw in the filtering that crept in in about April, long before anyone was even really thinking of allocating from 220.127.116.11/8. However, as I think everyone remembers, after a short while, in an effort to assist in getting aggregation of the then-announced bits of 18.104.22.168/8 working OK and giving people some time to get used to the filtering, I did relax the filtering on 22.214.171.124/8 to permit /19s. As you note, this was to the benefit of other peoples' customers. | the real message is if you have a 206+ address, make sure that your | provider can put it into an aggregation block for you (or go to sprint). Right, and we have been warning our customer base for some time that if they announce a 206+ address that is not aggregatable into something reasonably big (like a /18), they run the risk of losing connectivity to other providers if they ever were to impose similar filters for business or technical reasons. Meanwhile, yes, it's a slight competitive advantage. :-) (Frankly though, that was a at first side-effect of not having the ability to do the outbound filtering immediately, but it rapidly seemed like a smart thing to do to make other people think about similar filtering. An interesting thing to wonder about is how different the early days of CIDR deployment would have been if rather than aggregating at the source, people were to have set up some sort of inbound filtering at places like MAE-EAST.) | nobody said it would be boring. :-) Yup. Sean.
[ lir-wg Archives ]