On Sun, 11 February 2001, "Craig A. Huegen" wrote:
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.
Big doesn't mean right. Old doesn't mean wise. The net is full of "big" doing really dumb things, which the rest of us are stuck working around. Net 24 is a "big" example, or Net 12 in Class A space. Look at UNISYS's net 129.227/16 or any of the other examples in traditional Class B space.
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.
In general, if you look at most global enterprises who don't run Internet backbones, you'll also find they rarely have divergent routing policies. The AS Path is identical for all the locations because global enterprises have global purchase agreements. If you want to divide your /16 up within UUNET, fine. Just pay UUNET to aggregate your block before passing the announcement outside UUNET's network. Why do people forget you can aggregate blocks at points other than the edge of the network. If UNISYS had IBM aggregate 129.227/16, there is no reason why all those /24's need to appear in the global route table outside of IBM's network. UNISYS can pay IBM to get local trafic locally, but there is no reason why the rest of the global Internet needs to see those more specific paths. As you might have figured out, announcing more specifics is a nifty way to get around ISP peering handoffs, which is why some ISPs don't like listening to more specific announcements for the same organization. If I can dump the traffic onto Sony's california network block, why do I want to listen to a more specific announcement from Sony's european offices and carry the traffic on my backbone to europe.
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?
Except that is not what happens, and not really even good reason for dividing up their space. Access location has nothing to do with it. You divide up the space to announce different inter-provider path attributes, e.g. different AS Path, different MED, etc. If you use the same upstreams for all your locations, there is no reason why the rest of the global routing table needs to see your seperate access locations. Whether it is a /32 or a /16, if the global path is identical, then there is no reason for a more specific announcement. We don't need to know you have a 3000 access locations in your network. Yes, in the past there were networks who wanted to announce a seperate network for each dialup POP. Yes, there seems to be a constant influx of new people everyday who believe you must announce a seperate route for each access location in the global route table.
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.
Unfortunately, history has shown this is true. As you point out, most ISPs will listen to longer announcements *IF* you can give a good story. The reality is there are few good stories in comparison to the number of flawed attempts.
From what I read of the current big attempt, I haven't heard a good story yet. There are several alternatives, which given my limited knowledge, all seem to work for this situation.