Stephen Griffin wrote: ==>Returning a /16 which the organization is not entirely using for a smaller ==>block seems to be anything other than depletion. Perhaps I've misread ==>Dani's original message, but it appeared that the /16 is not being ==>completely used. The original poster didn't entirely make it clear whether the other remaining /18's would be used by other sections of the parent company, but that's not the point. If the space had been allocated from 206+ or 62/63/64, his announcements would have been accepted. Just because their parent company has been around for a while means that some ISP's penalize them. One could guess from his e-mail address that the parent company is one of the larger global enterprises in the world. When I refer to the depletion of immediately available address space, I refer to a company returning /16's, leaving an unallocated hole in the middle of 181/8 or 174/8 or 171/8 or whatever. The unallocated hole isn't as easily handed out by ARIN, because it's not a matter of serially handing out address space from a very large block; the process to hand out these "holes" would have to be considerably more costly to the organization. In fact, if you were a global enterprise today, and you asked ARIN for address space (because you were multi-homed), and they offered you the choice: 64/8 or 174/8 space, which would you take? Be careful with that answer if you haven't worked in or run a network for a global enterprise that has multiple Internet access locations. Global enterprises pay ISP's to deliver Internet traffic LOCALLY; they don't run Internet backbones, and they have no intention to. Therefore, they want to assign different addressing to different areas in order to have the ISP's bring traffic to the region with that addressing. This differs from the ISP model where traffic arrives at the closest possible entrypoint into the network, then follows a backbone to its destination. (We're talking about standard hot-potato, so try not to be too critical on semantics with content providers, cold potato, and that ball of wax.) ==>> Why not adopt a reasonable policy to accept up to /20's or up to /19's in ==>> the old B space so that organizations who already have these blocks can ==>> use them? ==> ==>Most people who filter feel that filtering on registry boundaries is ==>reasonable. There are people who feel that their version of reasonable ==>is more reasonable. What makes /32 less reasonable than /20? If one ==>filters on registry boundaries, the only time you don't have access to ==>an entity is when they are not announcing the allocation they have been ==>assigned. I feel that filtering on registry boundaries is reasonable; but that of course it depends on what you believe the registries' intentions are. If a registry is currently handing out blocks with a minimum size of /20, is it reasonable to filter all space other than the dump and swamp to /20? No problems here. I don't want the UUnet deaggregation disaster of the past to happen in 128/2. And chances are, if someone's announcing 256 /24's in their class B block, they're misconfigured. Fine. Protect against that. But is there a good reason that a block size of /19 shouldn't be accepted in this space? Is it not reasonable for an older global enterprise to want more Internet access locations for their enterprise, and therefore divide their address space up a bit more? Some ISP's believe that when the registries allocated address space in the B space prior to CIDR times, that they intended for those companies only to announce that space as /16's. Okay, I can accept that, given the landscape at the time. However, the flaw that these ISP's are making in policy is the belief that all the organizations who received this space in the past won't use VLSM, and can't be responsible with addressing. Note that most ISP's are accepting the /19's or /20's. There are only a small handful who are not accepting them. Of them, there are a few more who are willing to make exceptions if you ask nicely and provide a good reason. Others are not, and eventually the topic will come to a head as it did with content vs access wars. /cah