[arin-ppml] ARIN Multiple Discrete Networks Policy
Richard A Steenbergen
ras at e-gerbil.net
Thu Oct 6 03:42:15 EDT 2011
On Thu, Oct 06, 2011 at 01:42:52AM -0400, Heather Schiller wrote:
> You are claiming geographic distance and diversity..for a single
> network, under a single ASN, with a location at X and a location at Y
> (presumably very far apart, with different providers servicing them?)
Yes, which seems to be the textbook definition of that clause.
> ..and until now, you had a single allocation or assignment, that was
> subnetted between X and Y. Now X needs space and Y has some available
> space - are you saying that because of routing policy you can not pull
> address space from Y for X? or is it because of your existing
> utilization/subnetting design that you can't use space from Y for X?
Technically speaking we had MDN allocations in the past, but at some
point ARIN decided they didn't want to do them any more because they
believed "having any backbone at all means you don't have a discrete
network", and at the time it just wasn't worth the effort to try and
argue with them over it.
This time we decided that rather than just deaggregate and fill the
Internet with yet more useless /24s, we would try to actually get the
policy fixed. We ran the above issue all the way up to John, and he
affirmed that we were correct and that having a backbone did NOT exclude
you from having multiple discrete networks... But then immediately after
that, he decided to toss on some extra requirements that don't exist in
the policy, like "and you can't possibly solve the problem any other
way", and thus here we are...
> Are the netblocks you have available in Y smaller than /24? Is that
> part of why they can't be moved? If so, I could understand saying "I
> can't move the available space across the country, because the block
> would be too small to be globally announced by my upstream- resulting
> in off net traffic being drawn to my other location/provider resulting
> in a suboptimal path (if any..)" Or is it just that you don't want to
> deaggregate the prefix you currently have?
I don't want to deaggregate the space, and nothing in the policy says I
have to. The policy says meet one of these example compelling reasons to
run discrete networks, and our use case is a textbook perfect example of
example #2 (and I challenge anyone to think of a better example). That
should be it.
This about it this way: The number one prime example use for this policy
that EVERYONE seems to think is 100% legitimate is "the poor network
with two POPs that aren't connected at all", right? So imagine an
example user with two discontiguous networks who is given a /19, they
split them up into 2x /20s, and then network A grows faster than network
B and they need to apply for more space. If you now apply this new "and
you can't possibly solve it with deaggregation" rule to them, you should
be telling them "sorry why don't you go announce some /24s from network
B over on network A to solve your problem".
NOTHING about the existance or lack of existance of a backbone changes
the ability to use deaggregates as a workaround IN ANY WAY. It is JUST
as easy for any network to announce a deaggregate /24, and it behaves
EXACTLY the same, this is the part that seems to be flying right over
some people's heads. The ONLY counterpoint that has been raised to this
was John's "but there are some organizations that are so screwed up that
they can't figure out how to swip space between A and B", which may or
may not be true, but this ALSO has NOTHING to do with the existance or
lack of existance of a backbone.
I just don't get what is so hard about this concept... discrete networks
are simply a state of configuration, and their use requires
justification if you expect to get anything out of ARIN as a result. One
possible justification is having physically discontiguous networks,
another possible justification is weird political or legal requirements,
another possible justification is a single network/asn but with extreme
geographic and transit diversity needs which require unique routing
policies as a result... If you have one of these justifications, you
have a reason to run your networks discretely, and boom you're done. Why
is there this bizaare insistance on adding a special "and you also can't
possibly work around it by any other means" rule to the justifications
above, but only to the one and not the other, when there is ABSOLUTELY
NOTHING DIFFERENT about the behavior or the possible use of this
"workaround" between the different types of justiifcations?
> How is the diversity of your connectivity forcing you to have a unique
> routing policy?
Please see previous discussion re: "if I want to have unique transit
providers for each discrete network (which can EASILY be a requirement
due to large geographic distances being spanned), I need unique routing
> Part of me thinks that MDN for IPv4 has seen its time, and the policy
> should be obsoleted. We are at rearranging the deckchairs time for
> IPv4 and massive deaggregation is very likely going to be the next
> step. Folks should be making the most efficient use of the space they
> have, where they can, possibly sacrificing some aggregation in the
> process. I think that day is coming, just not sure if its here
> already or not. I suppose that depends on how altruistic we feel
> about being efficient with what we've already been allocated, so that
> resources are available for others.
The IPv4 space will run out on its own soon enough... I just don't see
how the incredibly small amount of increased overhead on an incredibly
small number of allocations is even REMOTELY worth the additional impact
to the routing table, which we'll all have to live with for MANY MANY
years to come, long after the v4 space from the RIRs is all exhausted.
Please don't cause me 5 years of unnecessary grief just to extend the v4
space for another week, I have more than enough routers with more than
enough problems correctly handling large numbers of bgp paths and/or fib
entries as it is. :)
Richard A Steenbergen <ras at e-gerbil.net> http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
More information about the ARIN-PPML