[arin-ppml] ARIN Multiple Discrete Networks Policy

[Richard A Steenbergen]

On Mon, Oct 03, 2011 at 04:56:51PM +0000, John Curran wrote:
> 
> Do you have a compelling reason to implement _discrete_ networks
> or simply unique routing policies?  You have again equated the
> two, despite lack of any policy language which supports that.
>
> As written, the policy doesn't provide any basis for consideration of 
> the routing as a basis for _discrete networks_. There is a basis for 
> viewing regulatory restrictions for data transmission, geographic 
> distance and diversity requirements, and autonomous multihomed 
> discrete networks as being compelling reasons for discrete networks:

Annnnnnd now we go back to that other argument again, weeee....

1) So far everyone who has responded to this thread has said that a 
requirement to implement unique routing policies *IS* what defines a 
discrete network.

2) The policy itself DOES provide a link between the need for unique 
routing policies and the need to implement discrete networks, right 
here:

> Some organizations have requirements for multiple discrete networks 
> that need individual address allocations. Discrete networks must often 
> have separate unique globally routable address space and will often 
> grow at different rates.

3) Earlier we were debating the definition of a discrete network and the 
the arbitrary exclusionary rule you have added to the policy, and you 
said that your objection was to the part where we matched the compelling 
reasons for running multiple discrete networks. Now that I've shown we 
match the compelling reasons for running multiple discrete networks, 
your objection is back to the definition of discrete networks.

You're seriously trying to argue that we don't match the compelling 
reasons for implementing discrete networks, not because we don't match 
the criteria, but because what we're implementing is not a discrete 
network... And then saying that what we're implementing is not a 
discrete network because we didn't match the compelling reasons. I 
really need to get ahold of whatever you're smoking here, it must be 
worth a fortune.

I appreciate recursiveness as much as the next programmer, but you can't 
use B to prove A and A to prove B if both A and B have already been 
disproven!

> Geographic distance and diversity requirements:
>   "While I do have what appears to be a single network, I've already
>    allocated address blocks to my POPs which I cannot rearrange and 
>    I cannot transit traffic between these two sets of POP due to 
>    the geographic distance and latency would result, and/or the lack
>    of redundancy in the my services that would result... Hence, we
>    consider those two sets of POPs to be discrete networks."

What does "I've already allocated address blocks to my POPs, which I 
cannot rearrange", have to do with "geographic distance and diversity 
requirements"? Where does this language come from? What is your basis in 
the policy to support this claim? When has this claim ever been applied 
to any other MDN applicant? And for the record, that part *IS* 
completely true in my specific situation, so it's not even a blocker, 
but it's also complete nonsense too, and needs to be called out as such.

The part that I *JUST* explained was "I cannot transit traffic between 
two sets of POPs due to the geographic distance and latency which would 
result, AND the lack of redundancy in my services that would result". 
This is *PRECISELY* what I *JUST DESCRIBED*, you couldn't have said it 
any better. Do you have an argument you'd like to make about why the 
explanation I just provided does not precisely match the example you 
just gave?

> *These are all COMPELLING REASONS for treating the infrastructure as 
> having _discrete networks_ precisely because they preclude the use of 
> network routing to make the existing allocation serve all of the 
> POPs.*

They are compelling reasons *BECAUSE*... wait for it... they require you 
to implement unique routing policies... Welcome to the definition of 
discrete network!

> If you can make use of your existing address allocations to meet your 
> needs, only with some routing impact as a result, you lack a 
> compelling reason to have your infrastructure treated as _discrete 
> networks_.  If you do not like this implementation of the MDN policy, 
> feel free to submit a change to policy to match your desired outcome.

No, you have a compelling reason if you can match an example compelling 
reason from the policy. NOTHING in the policy says ANYTHING about "and 
you can't solve this any other way", and your logic to try and make this 
claim is absolutely twisted to the point of being nonsensical.

To be clear, I really don't give a $%^(* about the allocation itself. I 
*CAN* get plenty of address space by doing things the hard way, I'm just 
trying to explain how woefully confused you are in the interests of not 
creating an even bigger mess for the Internet in general.

Or is that now grounds for denying an application too? :)

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