PI space and colocation

Mailman List Mirror (Read Only)
1

Questions:

If one gets PI space from ARIN for their network, then moves the servers
to a rack at a data center (still using the space efficiently), will most
colocation providers announce this space for them, or would most providers
require them to take allocated space from them?

Is it a reasonable alternative to establish a BGP connection with the
provider over ethernet?

Is this ok per ARINs requirements, assuming you first acquired this space
under their multihomed network guidelines?

TIA,

James Smallacombe PlantageNet, Inc. CEO and Janitor
up@3.am http://3.am

2

If one gets PI space from ARIN for their network, then moves the servers
to a rack at a data center (still using the space efficiently), will most
colocation providers announce this space for them, or would most providers
require them to take allocated space from them?

I don't know about "most", but every one I've asked has done it.

You might need to sign an LOA.

Is it a reasonable alternative to establish a BGP connection with the
provider over ethernet?

It is technical feasible, but I don't think 'reasonable'. Stub ASes are pollution on the 'Net.

But that doesn't stop some people.

Is this ok per ARINs requirements, assuming you first acquired this space
under their multihomed network guidelines?

That I do not know, but would guess "no". (I would also guess they won't notice. =)

Of course, if the space is /20 or more, you qualify under other rules too.

3

If one gets PI space from ARIN for their network, then moves the servers
to a rack at a data center (still using the space efficiently), will most
colocation providers announce this space for them, or would most providers
require them to take allocated space from them?

I don't know about "most", but every one I've asked has done it.

We'd do it as long as everything looked legit (i.e. it really seems to be the customer's IP space).

Is it a reasonable alternative to establish a BGP connection with the
provider over ethernet?

It is technical feasible, but I don't think 'reasonable'. Stub ASes are pollution on the 'Net.

We've done this as well. Whats wrong with letting the customer use their ASN and BGP peering with them in your data center? They might even get a connection to someone else there and multihome again. Either way, the routes are getting into the global table...does the end of the aspath matter that much?

4

It adds zero useful data to the global table, but increases RAM, CPU, etc. on every router looking at the global table.

Given how vociferously people argue against items in the table which _do_ add useful data, superfluous info should be avoided whenever possible. IMHO, of course.

5

Once upon a time, Patrick W. Gilmore <patrick@ianai.net> said:

It adds zero useful data to the global table, but increases RAM, CPU,
etc. on every router looking at the global table.

How much difference is there between one AS (the colo provider)
announcing a prefix and another AS (the customer) announcing it through
the first AS (the colo provider)? If the space is ARIN assigned PI, it
isn't going to aggregate with the colo provider's space, so the prefix
will still be a separate announcement. The only difference is the AS
path is one entry longer.

6

Well, obviously, the path entry is longer. :slight_smile:

It's not huge, but it is there. And like I said, many people argue over additions to the table which are actually useful.

7

Well, obviously, the path entry is longer. :slight_smile:

Yeah and if they (somehow) obtain an ASN for this non-multihoming venture then that completely wastes an ASN for no good. And as we all know there aren't an infinite number of those either.

8

Thus spake "Chris Adams" <cmadams@hiwaay.net>

Once upon a time, Patrick W. Gilmore <patrick@ianai.net> said:

It adds zero useful data to the global table, but increases RAM, CPU,
etc. on every router looking at the global table.

How much difference is there between one AS (the colo provider)
announcing a prefix and another AS (the customer) announcing it through
the first AS (the colo provider)? If the space is ARIN assigned PI, it
isn't going to aggregate with the colo provider's space, so the prefix
will still be a separate announcement. The only difference is the AS
path is one entry longer.

Routing slots aren't the only resource you're consuming. In general, many of the prefixes coming out of a given AS have common attributes, e.g. path, MEDs, etc. Those attributes are stored only once (at least in the BGP implementation I know) even if they're used by hundreds of prefixes. If you attach a new leaf AS, it must, by necessity, consume another one of those slots. If the customer prefix were announced by the upstream, however, it would not require an additional attribute slot; it'd reuse one of the existing ones.

Now, I'm not aware that there's any serious shortage of attribute slots like there is routing slots, but there's no sense wasting them if there's no gain to be had doing it. Save your (and everyone else's) RAM for more prefixes.

S

Stephen Sprunk "Stupid people surround themselves with smart
CCIE #3723 people. Smart people surround themselves with
K5SSS smart people who disagree with them." --Aaron Sorkin

9

Routing slots aren't the only resource you're consuming. In general, many of the prefixes coming out of a given AS have common attributes, e.g. path, MEDs, etc. Those attributes are stored only once (at least in the BGP implementation I know) even if they're used by hundreds of prefixes. If you attach a new leaf AS, it must, by necessity, consume another one of those slots. If the customer prefix were announced by the upstream, however, it would not require an additional attribute slot; it'd reuse one of the existing ones.

Now, I'm not aware that there's any serious shortage of attribute slots like there is routing slots, but there's no sense wasting them if there's no gain to be had doing it. Save your (and everyone else's) RAM for more prefixes.

I think that this deserves a bit more explanation...

Most implementations use an "attribute cache". An entry in this cache typically consists of a
set of different attributes. Which attributes constitute a cache entry is entirely up to the
implementation. Each prefix will have a number of paths. Each path will point to an attribute cache entry and also contain one or more other uncached attributes. Individual attributes themselves
may also be cached.

The primary attribute cache may or may not include the AS path. If it does not, it is very likely
that there is a cache for the AS paths. Again, this is all implementation dependent.

If an implementation does cache AS paths independently from the attribute cache, then the cost
of a stub AS is only one more AS path entry in the AS path cache. If an implementation
does not cache AS paths independently, then creating a stub AS will create a new
attribute cache entry, complete with AS path.

Regardless of this, it should be noted that this is only using BGP table RAM. This should not
affect the main routing table or the forwarding table. Having an additional PI prefix in the
first place is the expensive part, as that does consume BGP RAM, routing table RAM and
forwarding table entries.

IMHO, wasting any resource is unfortunate, but the cost of additional forwarding table entries
far outstrips the cost of additional DRAM. Thus, adding an additional prefix does merit
a significant shout from others, but the stub AS should only be an incremental whimper.

Regards,
Tony

10

If one gets PI space from ARIN for their network, then moves the servers

    > to a rack at a data center (still using the space efficiently), will most
    > colocation providers announce this space for them, or would most providers
    > require them to take allocated space from them?

Most larger colo providers will do so happily, provided you have
sufficient expertise to operate your own BGP router and make the
announcement to them.

    > Is it a reasonable alternative to establish a BGP connection with the
    > provider over ethernet?
    
Yes.

    > Is this ok per ARINs requirements, assuming you first acquired this space
    > under their multihomed network guidelines?

It's okay regardless of the policy under which you received the space.

                                -Bill

11

It's not just the amount of resources spent, it's what you get for them.

Spending a little on nothing is worse than spending more on something useful.

Personally, I think a prefix which gives routability info is useful. A Stub AS is just a waste.

12

Patrick W. Gilmore wrote:

Is it a reasonable alternative to establish a BGP connection with the
provider over ethernet?

It is technical feasible, but I don't think 'reasonable'. Stub ASes are pollution on the 'Net.

OK, let's try a similar but different scenario. Customer has ISP A, adds ISP B ("you"). Customer intends to disconnect from ISP A. Assuming the customer told you, do you require the customer to start their connection with you as a private AS, do you require the customer to re-AS-number later, or do you assume the customer will re-multihome, etc.?

And what if the customer doesn't tell you that they're intending to leave ISP A? Do you police this, and if so how regularly?

(And yes, Patrick, IKYNAI. We'll pretend for the moment.)

pt

13

Patrick W. Gilmore wrote:

Is it a reasonable alternative to establish a BGP connection with the
provider over ethernet?

It is technical feasible, but I don't think 'reasonable'. Stub ASes are pollution on the 'Net.

OK, let's try a similar but different scenario. Customer has ISP A, adds ISP B ("you"). Customer intends to disconnect from ISP A. Assuming the customer told you, do you require the customer to start their connection with you as a private AS, do you require the customer to re-AS-number later, or do you assume the customer will re-multihome, etc.?

First: Customer is probably not already doing BGP, since they are single homed to ISP A. When they connect to me, if they honestly plan to dump ISP B ("you" :), then they probably won't want to go through the hassle of setting up BGP. Of the literally millions of "customers" in the world, there are only a few thousands (say, on the order of 0.1%) who want or do BGP.

Assuming they tell you their plans, why wouldn't you rather just originate their prefixes and static route to them? They can be multi-originated for a while, doesn't hurt anything. Certainly better than adding superfluous info into the global table permanently.

Easier for you, easier for them, and better for the Internet. Why wouldn't you do it?

And what if the customer doesn't tell you that they're intending to leave ISP A? Do you police this, and if so how regularly?

Of course you should police it, but it ain't the end of the world. How often? How about when you get around to it, or maybe when someone notifies you?

I'm not suggesting stub ASes should be disallowed by law. It's just when someone asks, why wouldn't you suggest not doing it? If they customer screams, well, they're paying you (or someone else if you don't do it), so I guess you kinda have to do it.

I'm confused at the few (three, if I include you) people who are questioning this. Are any of you honestly advocating stub ASNs and other completely useless info should be encouraged in the global table?

(And yes, Patrick, IKYNAI. We'll pretend for the moment.)

Doesn't stop me from commenting. :slight_smile: