[arin-ppml] ARIN Multiple Discrete Networks Policy
Richard A Steenbergen
ras at e-gerbil.net
Mon Oct 3 17:00:12 EDT 2011
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
2) The policy itself DOES provide a link between the need for unique
routing policies and the need to implement discrete networks, right
> 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
> 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
> *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
They are compelling reasons *BECAUSE*... wait for it... they require you
to implement unique routing policies... Welcome to the definition of
> 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)
More information about the ARIN-PPML