Re: BGP Question - how do work around pigheaded ISPs
On Fri, 09 February 2001, "Roisman, Dani" wrote:
A parent organization has an unused /16 of address space, for arguments sake, let's say it's 172.16.0.0/16. It's out of the old "class B" address range. Two groups within the organization want to bring up independant Internet datacenters, and need /18 of address space, each. Since the parent organization owns an unsed /16, the IP registry refuses to give the child organizations any address space - they insist all address blocks assigned to the parent organization be used, first.
ISPph (ph=pigheaded) has a BGP policy that filters out all routes in 128.0.0.0/2 longer than /16.
Return the 172.16.0.0/16 block to the registry (ARIN, APNIC, RIPE or if no one else IANA) and apply for multiple appropriately sized CIDR blocks under the current registry allocation guidelines.
On Fri, Feb 09, 2001 at 09:18:40PM -0800, Sean Donelan wrote: ==>Return the 172.16.0.0/16 block to the registry (ARIN, APNIC, RIPE or if ==>no one else IANA) and apply for multiple appropriately sized CIDR blocks ==>under the current registry allocation guidelines. While I fully agree with this approach to deal with the issues mentioned, it will only exhaust the new address space more quickly. Why should we give up on 128/2? /cah
Return the 172.16.0.0/16 block to the registry (ARIN, APNIC, RIPE or if no one else IANA) and apply for multiple appropriately sized CIDR blocks under the current registry allocation guidelines. While I fully agree with this approach to deal with the issues mentioned, it will only exhaust the new address space more quickly. Why should we give up on 128/2?
because when the registries have different allocation policies in 128/2, the isps will follow. just as we did in old A space. randy
On Sat, Feb 10, 2001 at 06:53:41AM -0800, Randy Bush wrote: ==> ==>>> Return the 172.16.0.0/16 block to the registry (ARIN, APNIC, RIPE or if ==>>> no one else IANA) and apply for multiple appropriately sized CIDR blocks ==>>> under the current registry allocation guidelines. ==>> While I fully agree with this approach to deal with the issues mentioned, ==>> it will only exhaust the new address space more quickly. Why should we ==>> give up on 128/2? ==> ==>because when the registries have different allocation policies in 128/2, ==>the isps will follow. just as we did in old A space. That doesn't address the point -- the point is that these ISP's are forcing the exchange of these blocks for new, previously unallocated space, and leaving holes in the old 128/2 space. These ISP's are massively contributing to the depletion of immediately available address space. 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? /cah
In the referenced message, Craig A. Huegen said:
On Sat, Feb 10, 2001 at 06:53:41AM -0800, Randy Bush wrote: ==> ==>>> Return the 172.16.0.0/16 block to the registry (ARIN, APNIC, RIPE or if ==>>> no one else IANA) and apply for multiple appropriately sized CIDR blocks ==>>> under the current registry allocation guidelines. ==>> While I fully agree with this approach to deal with the issues mentioned, ==>> it will only exhaust the new address space more quickly. Why should we ==>> give up on 128/2? ==> ==>because when the registries have different allocation policies in 128/2, ==>the isps will follow. just as we did in old A space.
That doesn't address the point -- the point is that these ISP's are forcing the exchange of these blocks for new, previously unallocated space, and leaving holes in the old 128/2 space. These ISP's are massively contributing to the depletion of immediately available address space.
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.
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.
/cah
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
In the referenced message, Craig A. Huegen said:
On Fri, Feb 09, 2001 at 09:18:40PM -0800, Sean Donelan wrote:
==>Return the 172.16.0.0/16 block to the registry (ARIN, APNIC, RIPE or if ==>no one else IANA) and apply for multiple appropriately sized CIDR blocks ==>under the current registry allocation guidelines.
While I fully agree with this approach to deal with the issues mentioned, it will only exhaust the new address space more quickly. Why should we give up on 128/2?
/cah
When the blocks are returned to the registries, the registries may use them for allocation at their current prefix boundaries (/19 generally) just as they are doing with 24,61,62,63,64,65,66. I'ld say the vast majority of those who filter do so based at minimum on the minimum registry allocation guidelines. cf BCP4 To add to Sean's solution, I believe it would not be outside the realm of possibility that a RiR would not require an entity to return first, ask second. Working with them on sizing an appropriate block, and setting up a generous renumbering schedule would probably be entirely possible. To add another potential solution, since both of the entities mentioned are, in effect, part of the same organization, set up (a/multiple) GRE tunnels for sending data between the two orgs. Then announce the larger aggregate from the better connected of the two.
participants (4)
-
Craig A. Huegen -
Randy Bush -
Sean Donelan -
Stephen Griffin