[arin-ppml] ARIN Multiple Discrete Networks Policy

[Richard A Steenbergen]

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 
policies". :)

> 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)