[arin-ppml] ARIN Multiple Discrete Networks Policy
Richard A Steenbergen
ras at e-gerbil.net
Fri Sep 30 22:20:43 EDT 2011
On Fri, Sep 30, 2011 at 10:41:37PM +0000, John Curran wrote:
> If network #2 is the mobile wireless business unit, it might be next
> to impossible to reallocate the space once it's been allocated.
How so? They can't work SWIP? Everyone else manages to do it just fine.
Are you saying that every recipient of a multiple discrete network
allocation is someone in some goofy circumstance of corporate insanity?
Because it seems to me that anyone who can work SWIP and BGP is
perfectly capable of having network #1 steal a /24 from network #2's
space, and thus by your logic make the MDN policy apply to almost no
> Actually, it's a very useful policy for organizations that actually
> have multiple discrete networks, but not useful for networks with
> multiple POPs that are seeking to use the policy to avoid having to
> break up their space into smaller blocks with corresponding smaller
> routing announcements.
I'd have to disagree with this as well. Again, from the text of the
> The organization must have compelling criteria for creating discrete
> networks. Examples:
> * regulatory restrictions for data transmission
> * geographic distance and diversity between networks
> * autonomous multi-homed discrete networks
Lets consider the example "geographic distance and diversity between
networks", which is specifically listed as a compelling reason. The
geographic diversity angle seems simple enough, if a network has (for
example) a presence in Miami and a presence in Seattle, it could be
quite sensible for them to operate these two regions as discrete
networks in order to ensure optimal routing. Similarly, it would be
quite reasonable to assume that they may need/want diverse transit
providers in each region (e.g. buy from someone in Seattle who doesn't
have a presence in Miami, and vice versa), which would also require
operating as discrete networks.
Clearly "every pop" isn't deserving of being treated as a discrete
network (e.g. two pops in the same city), but the policy very
specifically outlines geographic distances and network diversity as
compelling reasons. Sure you could argue that "geographic distance"
isn't defined, but I think you'd have a hard time arguing that something
like Miami to Seattle doesn't qualify, considering it spans almost all
of the ARIN region.
It seems to me that you're deliberately ignoring a portion of the policy
as written. If the community would like to change it, then fine, but I
think the policy as its written today seems perfectly clear on the above
> Richard - The policy allows an organization to obtain address space
> under circumstances where there are multiple distinct networks. In
> these circumstances, the allocations cannot be aggregated and must be
> announced separately. That does not make the point of the policy to
> be improved aggregation, the intent of the policy is to allow use of a
> single maintainer id for organizations with multiple discrete networks
> and this is clearly described in the original policy submission:
I'm not sure how I'm not being clear here. Perhaps if we break this up
into two components.
Question: Does the organization have a compelling reason to operate
multiple discrete networks?
Answer: The policy as written lists 3 very specific examples which serve
as compelling reasons for creating multiple discrete networks. If the
situation of the applicant matches one of these examples, then the
answer would seem to be "yes they do have a compelling reason", and we
move on to part 2.
Question: What does ARIN need to do about it, in regards to the MDN
Answer: As you just said, in the circumstances of someone operating
multiple discrete networks, the allocation cannot be aggregated and must
be announced separately. And as you just said in the previous email,
"the policy was designed to address the circumstances where the
allocation cannot be aggregated and must be announced separately".
Therefore, if there IS a compelling reason (as defined by the policy)
for creating multiple discrete networks, and all the other policy
requirements are met, how is it that the policy doesn't apply?
Notice how "aggregation" has ABSOLUTELY NOTHING to do with the
compelling reason to run multiple discrete networks. But if you *DO*
have a compelling reason, then as a consequence you *MUST* announce each
route separately (your words), and thus the policy exists to help you
obtain address space which can be announced separately (your words).
This is the only context in which I'm using "aggregation", where you
yourself have said the policy acts to provide it.
> Your interpretation is incorrect, but that does not mean that a policy
> change to allow for improved aggregation for additional ISP requests
> is not worth considering. Hopefully, we can get some discussion here
> of the value of such a change, and whether it should be for all ISPs,
> ISPs who have distinct AS routing domains, or some other criteria.
I'm completely baffled how you can say in one breath "the policy exists
to handle the situation where the allocations cannot be aggregated and
must be announced separately", and then say "the policy has nothing to
do with aggregation" in the next.
The logic seems blindly clear to me:
IF you have a compelling reason to run multiple discrete networks
THEN you have a circumstance where things must be annouced separately
IF you have a circumstance where things must be announced separately
THEN the policy exists to help you obtain address space
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