PI space and colocation
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 =========================================================================
On Jan 18, 2006, at 2:41 PM, up@3.am wrote:
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. -- TTFN, patrick
On Wed, 18 Jan 2006, Patrick W. Gilmore wrote:
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? ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________
On Jan 18, 2006, at 3:03 PM, Jon Lewis 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.
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?
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. -- TTFN, patrick
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. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On Jan 18, 2006, at 4:02 PM, Chris Adams wrote:
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.
Well, obviously, the path entry is longer. :) It's not huge, but it is there. And like I said, many people argue over additions to the table which are actually useful. -- TTFN, patrick
--On January 18, 2006 5:21:35 PM -0500 "Patrick W. Gilmore" <patrick@ianai.net> wrote:
Well, obviously, the path entry is longer. :)
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.
It's not huge, but it is there. And like I said, many people argue over additions to the table which are actually useful.
-- TTFN, patrick
-- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler
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
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
On Jan 18, 2006, at 6:22 PM, Tony Li wrote:
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.
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. -- TTFN, patrick P.S. This also means a /24 with the same AS path as the enclosing /16 is also a waste - an even bigger one.
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
On Jan 19, 2006, at 3:02 PM, Pete Templin wrote:
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. :-) -- TTFN, patrick
i On Wed, 18 Jan 2006 up@3.am wrote: > 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
participants (9)
-
Bill Woodcock -
Chris Adams -
Jon Lewis -
Michael Loftis -
Patrick W. Gilmore -
Pete Templin -
Stephen Sprunk -
Tony Li -
up＠3.am