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.