Hi there... I'm in a meeting next week to discuss settlement-free peering etc..... always an interesting time. A push is on (by myself) to get into other physical locations and participate on the peering exchanges. Besides costs, what other factors are benefits to peering? I can think of some but looking to develop a concrete list of appealing reasons etc. such as: -control over routing between networks -security aspect (being able to filter/verify routes to some degree) -latency/performance Just looking for other positive ideas etc...;) Cheers! Paul ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said:
I can think of some but looking to develop a concrete list of appealing reasons etc. such as:
-control over routing between networks -security aspect (being able to filter/verify routes to some degree) -latency/performance
I'm surprised you didn't include "chance to pick up a redundant connection".
Thanks! That's a really good one and surprised myself I missed it..;) _____________________________________________ From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Wednesday, October 29, 2008 3:28 PM To: Paul Stewart Cc: nanog@nanog.org Subject: Re: Peering - Benefits? * PGP Signed by an unknown key On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said:
I can think of some but looking to develop a concrete list of appealing reasons etc. such as:
-control over routing between networks -security aspect (being able to filter/verify routes to some degree) -latency/performance
I'm surprised you didn't include "chance to pick up a redundant connection". * Unknown Key * 0xB4D3D7B0 ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
It would only be a redundant connection if the AS your peering with is a transit AS. The AS that I work with is a stub AS and can not function as a fully redundant link. Just something to watch out for. Paul Stewart wrote:
Thanks! That's a really good one and surprised myself I missed it..;)
_____________________________________________ From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Wednesday, October 29, 2008 3:28 PM To: Paul Stewart Cc: nanog@nanog.org Subject: Re: Peering - Benefits?
* PGP Signed by an unknown key
On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said:
I can think of some but looking to develop a concrete list of
appealing
reasons etc. such as:
-control over routing between networks -security aspect (being able to filter/verify routes to some degree) -latency/performance
I'm surprised you didn't include "chance to pick up a redundant connection".
* Unknown Key * 0xB4D3D7B0
----------------------------------------------------------------------------
"The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
-- Steve King Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional
Thanks - I believe the wording meant was "alternative path" versus connection... in other words if an AS has issues with one or more upstream providers for whatever reason, you have good chances the peering connection will remain in better shape (not always granted, but good odds).... Paul -----Original Message----- From: Steven King [mailto:sking@kingrst.com] Sent: October 29, 2008 6:22 PM To: Paul Stewart Cc: Valdis.Kletnieks@vt.edu; nanog@nanog.org Subject: Re: Peering - Benefits? It would only be a redundant connection if the AS your peering with is a transit AS. The AS that I work with is a stub AS and can not function as a fully redundant link. Just something to watch out for. Paul Stewart wrote:
Thanks! That's a really good one and surprised myself I missed it..;)
_____________________________________________ From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Wednesday, October 29, 2008 3:28 PM To: Paul Stewart Cc: nanog@nanog.org Subject: Re: Peering - Benefits?
* PGP Signed by an unknown key
On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said:
I can think of some but looking to develop a concrete list of
appealing
reasons etc. such as:
-control over routing between networks -security aspect (being able to filter/verify routes to some degree) -latency/performance
I'm surprised you didn't include "chance to pick up a redundant connection".
* Unknown Key * 0xB4D3D7B0
------------------------------------------------------------------------ ----
"The information transmitted is intended only for the person or entity
to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
-- Steve King Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
But if that AS is a stub, you still can't use their up stream providers to get data out to the rest of the world. It still wouldn't even function as an "alternative path" it would only function for the subnets which that AS owns. Paul Stewart wrote:
Thanks - I believe the wording meant was "alternative path" versus connection... in other words if an AS has issues with one or more upstream providers for whatever reason, you have good chances the peering connection will remain in better shape (not always granted, but good odds)....
Paul
-----Original Message----- From: Steven King [mailto:sking@kingrst.com] Sent: October 29, 2008 6:22 PM To: Paul Stewart Cc: Valdis.Kletnieks@vt.edu; nanog@nanog.org Subject: Re: Peering - Benefits?
It would only be a redundant connection if the AS your peering with is a transit AS. The AS that I work with is a stub AS and can not function as a fully redundant link.
Just something to watch out for.
Paul Stewart wrote:
Thanks! That's a really good one and surprised myself I missed it..;)
_____________________________________________ From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Wednesday, October 29, 2008 3:28 PM To: Paul Stewart Cc: nanog@nanog.org Subject: Re: Peering - Benefits?
* PGP Signed by an unknown key
On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said:
I can think of some but looking to develop a concrete list of
appealing
reasons etc. such as:
-control over routing between networks -security aspect (being able to filter/verify routes to some degree) -latency/performance
I'm surprised you didn't include "chance to pick up a redundant connection".
* Unknown Key * 0xB4D3D7B0
------------------------------------------------------------------------ ----
"The information transmitted is intended only for the person or entity
to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
-- Steve King Network Engineer - Liquid Web, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional
Sure, but we're talking about settlement-free peering. He's only expecting to be able to reach his peer's subnets and perhaps those of his peer's customers. If he peers with ASx in two locations, he does have redundant connections to ASx's tiny corner of the internet. adam.
But if that AS is a stub, you still can't use their up stream providers to get data out to the rest of the world. It still wouldn't even function as an "alternative path" it would only function for the subnets which that AS owns.
Paul Stewart wrote:
Thanks - I believe the wording meant was "alternative path" versus connection... in other words if an AS has issues with one or more upstream providers for whatever reason, you have good chances the peering connection will remain in better shape (not always granted, but good odds)....
Paul
-----Original Message----- From: Steven King [mailto:sking@kingrst.com] Sent: October 29, 2008 6:22 PM To: Paul Stewart Cc: Valdis.Kletnieks@vt.edu; nanog@nanog.org Subject: Re: Peering - Benefits?
It would only be a redundant connection if the AS your peering with is a transit AS. The AS that I work with is a stub AS and can not function as a fully redundant link.
Just something to watch out for.
Paul Stewart wrote:
Thanks! That's a really good one and surprised myself I missed it..;)
_____________________________________________ From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Wednesday, October 29, 2008 3:28 PM To: Paul Stewart Cc: nanog@nanog.org Subject: Re: Peering - Benefits?
* PGP Signed by an unknown key
On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said:
I can think of some but looking to develop a concrete list of
appealing
reasons etc. such as:
-control over routing between networks -security aspect (being able to filter/verify routes to some degree) -latency/performance
I'm surprised you didn't include "chance to pick up a redundant connection".
* Unknown Key * 0xB4D3D7B0
------------------------------------------------------------------------ ----
"The information transmitted is intended only for the person or entity
to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
internet exchanges are not per-se "redundant" they basically are a switch which actually, because of the many connected parties, most of which do not have enough PAID transit to cover any outages on it, causes more problems than they are good for. (the amsix with their many outages and connected parties that rely primarliy on it's functionality is a prime example here) internet exchanges usually are some sort of hobby computer club, you cannot rely on them to actually -work-, but when they do work that's "nice" (always make sure you have enough paid capacity to cover for it when they do not work however!) peering on only one of them therefore does not make your network more reliable in any way (it becomes a different story when you connect to like 10 or so worldwide). as for "peering" agreements, just implement an open peering policy (doesn't nessesarily have to take place over an ix, also applies to pieces of ethernet running from your network to others). those basically are contracts that force anyone who has also signed one to peer with your network, wether they like you or not (saves the trouble when you are a content provider and others do not want to peer with you because they provide content too and you are a competing party etc). -- HRH Sven Olaf Prinz von CyberBunker-Kamphuis, MP. Minister of Telecommunications, Republic CyberBunker. Phone: +49/163-4405069 Phone: +49/30-36731425 Skype: CB3ROB MSN: sven@cb3rob.net C.V.: http://www.linkedin.com/in/cb3rob Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Wed, 29 Oct 2008, Paul Stewart wrote:
Thanks! That's a really good one and surprised myself I missed it..;)
_____________________________________________ From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Wednesday, October 29, 2008 3:28 PM To: Paul Stewart Cc: nanog@nanog.org Subject: Re: Peering - Benefits?
* PGP Signed by an unknown key
On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said:
I can think of some but looking to develop a concrete list of appealing reasons etc. such as:
-control over routing between networks -security aspect (being able to filter/verify routes to some degree) -latency/performance
I'm surprised you didn't include "chance to pick up a redundant connection".
* Unknown Key * 0xB4D3D7B0
----------------------------------------------------------------------------
"The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
X-CONTACT-FILTER-MATCH: "nanog"
Thanks - no I understand that... We have multiple transit providers today and are already present on a couple of smaller peering exchanges with an open peering policy... our experience with them has been very positive. The redundancy perspective is that you now have more paths to the same AS - and an assumption that the peering route will always be best (I know that's not always true). We of course have enough transit in case of a peering outage - would never "put all our eggs into one basket" that it sounds like some others are doing.... also, we are looking at a number of them in various parts of the world currently which adds another level of redundancy per say.... Take care, Paul -----Original Message----- From: HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP [mailto:sven@cyberbunker.com] Sent: Thursday, October 30, 2008 9:04 AM To: Paul Stewart Cc: Valdis.Kletnieks@vt.edu; nanog@nanog.org Subject: RE: Peering - Benefits? internet exchanges are not per-se "redundant" they basically are a switch which actually, because of the many connected parties, most of which do not have enough PAID transit to cover any outages on it, causes more problems than they are good for. (the amsix with their many outages and connected parties that rely primarliy on it's functionality is a prime example here) internet exchanges usually are some sort of hobby computer club, you cannot rely on them to actually -work-, but when they do work that's "nice" (always make sure you have enough paid capacity to cover for it when they do not work however!) peering on only one of them therefore does not make your network more reliable in any way (it becomes a different story when you connect to like 10 or so worldwide). as for "peering" agreements, just implement an open peering policy (doesn't nessesarily have to take place over an ix, also applies to pieces of ethernet running from your network to others). those basically are contracts that force anyone who has also signed one to peer with your network, wether they like you or not (saves the trouble when you are a content provider and others do not want to peer with you because they provide content too and you are a competing party etc). -- HRH Sven Olaf Prinz von CyberBunker-Kamphuis, MP. Minister of Telecommunications, Republic CyberBunker. Phone: +49/163-4405069 Phone: +49/30-36731425 Skype: CB3ROB MSN: sven@cb3rob.net C.V.: http://www.linkedin.com/in/cb3rob Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Wed, 29 Oct 2008, Paul Stewart wrote:
Thanks! That's a really good one and surprised myself I missed it..;)
_____________________________________________ From: Valdis.Kletnieks@vt.edu [mailto:Valdis.Kletnieks@vt.edu] Sent: Wednesday, October 29, 2008 3:28 PM To: Paul Stewart Cc: nanog@nanog.org Subject: Re: Peering - Benefits?
* PGP Signed by an unknown key
On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said:
I can think of some but looking to develop a concrete list of appealing reasons etc. such as:
-control over routing between networks -security aspect (being able to filter/verify routes to some degree) -latency/performance
I'm surprised you didn't include "chance to pick up a redundant connection".
* Unknown Key * 0xB4D3D7B0
------------------------------------------------------------------------ ----
"The information transmitted is intended only for the person or entity
to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
X-CONTACT-FILTER-MATCH: "nanog"
---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
Paul Stewart wrote:
We have multiple transit providers today and are already present on a couple of smaller peering exchanges with an open peering policy... our experience with them has been very positive.
As an IX operator I'm glad to hear it :-)
The redundancy perspective is that you now have more paths to the same AS - and an assumption that the peering route will always be best (I know that's not always true).
Something to remember is that you are a network *operator* not a network *purchaser*. If the peering route isn't working for you, pick up the phone and talk to your peering partner. The whole point of being a network operator is that you control who you connect with and take an active hand in fixing problems! As others have stated, rich interconnection gives you greater abilities in this area.
We of course have enough transit in case of a peering outage - would never "put all our eggs into one basket" that it sounds like some others are
That attitude is quite 'old-school' - the idea that you can back up your peering with transit often does not ring true in practice. You have less visibility into your transit providers network than into your IXes networks, and what information you do have is clouded by commercial concerns (read: sales bullshit). The traffic has to go somewhere, and if everyone in a metro area tries to send to their transits it will just result in congestion within those networks - even more likely when you consider the typical way their are built with ports tiered off at layer2 from routers; traffic in the same metro area is likely to simply hairpin up/down the router uplink. Traffic between major transits within a metro area is also subject to complicated commercial considerations which might mean the connectivity via that route isn't so great.
also, we are looking at a number of them in various parts of the world currently which adds another level of redundancy per say....
Many metro areas have more than one IX fabric often with considerable numbers of operators on both. At LONAP in London we have members with big ports expressly for backing up their private interconnects as well as to back up sessions at other IXes. In (primarily) Europe, the Euro-ix website has some useful resources to help people select IXes: e.g https://www.euro-ix.net/member/m/peeringmatrix Will
HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP wrote:
as for "peering" agreements, just implement an open peering policy (doesn't nessesarily have to take place over an ix, also applies to pieces of ethernet running from your network to others).
those basically are contracts that force anyone who has also signed one to peer with your network, wether they like you or not (saves the trouble when you are a content provider and others do not want to peer with you because they provide content too and you are a competing party etc).
It is not practice in this community for 'open peering policy' to mean 'must peer with anyone'. You might still refuse to peer on the basis that the other party is unreliable or run by idiots, and this is perfectly acceptable even with an advertised open peering policy. Nor does such a statement create any form of contract or obligation under any law I am aware of, as such an indicative offer does not fulfill the requirements to form a binding contract. Any device which has REQUIRED e.g. participants in an IX to peer with others has proved very unpopular in the industry.
On 30 Oct 2008, at 13:03, HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP wrote:
internet exchanges are not per-se "redundant"
Those networks who *choose* connect to peers via a single fabric, in a single location, will suffer a similar fate to those networks who single home to one transit provider.
(the amsix with their many outages and connected parties that rely primarliy on it's functionality is a prime example here)
I run interconnection for three networks connected to the ams-ix and can't understand why you think that the ams-ix fabric has "many outages" - I have found it, to borrow a phrase from another stable European IXP, rock solid.
internet exchanges usually are some sort of hobby computer club, you cannot rely on them to actually -work-,
You shouldn't bet the farm on a single one of anything. My alarm clock failed once, this doesn't mean that all alarm clocks are hobbyist timekeeping devices. Most internet exchanges are professional organisations run by a team of experts who care about the operational stability of the platform. Most in Europe are association based organisations, who's leaders are held accountable for the operational and commercial stability of the exchange, to all of the participants, at legally mandated meetings. Its a shame if your experience at the local IXP has been less positive, perhaps look at the procedures and policies of a more sound exchange and encourage your local IXP to be run along those lines. Andy
On 30 Oct 2008, at 13:03, HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP wrote:
internet exchanges are not per-se "redundant"
Those networks who *choose* connect to peers via a single fabric, in a single location, will suffer a similar fate to those networks who single home to one transit provider.
Are you referring to his royal highness' network? <http://www.cidr-report.org/cgi-bin/as-report?as=AS34109&v=4&view=2.0> In any case, if you are really interested in achieving highly reliable connectivity to the Internet, you need to start by engineering it into your design. It's not just a matter of choosing the right mix of peering and transit. <http://en.wikipedia.org/wiki/Reliable_system_design> --Michael Dillon
In article <9AFB2A51-6EE0-440C-9A71-4C0A4D678455@nosignal.org>, Andy Davidson <andy@nosignal.org> wrote:
On 30 Oct 2008, at 13:03, HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP wrote:
(the amsix with their many outages and connected parties that rely primarliy on it's functionality is a prime example here)
I run interconnection for three networks connected to the ams-ix and can't understand why you think that the ams-ix fabric has "many outages" - I have found it, to borrow a phrase from another stable European IXP, rock solid.
The AMS-IX is a service that is present at multiple colocation providers. One or two of these are, let's say, not state of the art anymore. But that's a colo issue and doesn't have anything to do with the AMS-IX network. This is different from the US, where an internet exchange is usually tied in with one colocation provider, so I can see where the confusion comes from. Mike.
HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP wrote:
internet exchanges are not per-se "redundant" they basically are a switch which actually, because of the many connected parties, most of which do not have enough PAID transit to cover any outages on it, causes more problems than they are good for. (the amsix with their many outages and connected parties that rely primarliy on it's functionality is a prime example here)
internet exchanges usually are some sort of hobby computer club, you cannot rely on them to actually -work-, but when they do work that's "nice" (always make sure you have enough paid capacity to cover for it when they do not work however!)
peering on only one of them therefore does not make your network more reliable in any way (it becomes a different story when you connect to like 10 or so worldwide).
as for "peering" agreements, just implement an open peering policy (doesn't nessesarily have to take place over an ix, also applies to pieces of ethernet running from your network to others).
those basically are contracts that force anyone who has also signed one to peer with your network, wether they like you or not (saves the trouble when you are a content provider and others do not want to peer with you because they provide content too and you are a competing party etc).
Dear me, that smells of extreme ignorance of the design and management of the major exchanges. LINX and AMS-IX for example go to great lengths to make sure their exchanges have high availability. I've had far fewer issues with individual exchanges with 100s of members than I have with single transit providers. The LINX for example provides TWO fabrics, and encourage members to peer on both of them. My transit providers have a single network which they break from time to time. It's far harder for an IX to break anything as they're less involved in the whole process. It is true, of course, that there are tiny badly-run exchanges run as a hobby, but just as it's best not to buy transit from a bargain-basement transit provider, I wouldn't trust any important traffic to one of the tiny exchanges. I'd say that LINX/AMS-IX are amongst the most reliable places you can pass your traffic. Since you bring up the "PAID" issue, as if to suggest that people who peer are cheap and don't care about their traffic, most organisations who peer do so to *improve* the performance of their networks. The cheaper route for me is not to buy a bunch of peering routers to manage 1000s of peering sessions, but I spend the extra cash to make the service I provide to my customers better. If you don't have the understanding or desire to provide the best service you can to your customers, perha1ps you'd like to become a politician? Peering on one would make youre network more reliable if you have sufficiently burstable transit links. Only a fool would try to offload 180mbit of traffic via 100mbit of transit and 100mbit of peering. User stupidity isn't the fault of the exchanges and certainly don't diminish the viability of internet exchanges as a concept. I think others have already rubbished your contracts nonsense, so I won't even bother. adam.
:-> "HRH" == HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP <sven@cyberbunker.com> writes: > internet exchanges are not per-se "redundant" depends on your concept of redundancy. > they basically are a switch which actually, because of the many > connected > parties, most of which do not have enough PAID transit to cover any > outages on it, causes more problems than they are good for. depends who you peer with, and your comment on the IX being "a switch" depends on which IX you connect to. > (the amsix with their many outages and connected parties that rely > primarliy on it's functionality is a prime example here) How many of the outages at AMS-IX really affected you directly? or weren't they rather limited to a bunch of your peers? And you know that you can get multiple links to separate switches in different location, don't you? Same goes for DE-CIX, LINX, the various Equinix, PAIX etc... > internet exchanges usually are some sort of hobby computer club, > you I think your choice of which internet exchanges to join has some flaws. > cannot rely on them to actually -work-, but when they do work that's > "nice" (always make sure you have enough paid capacity to cover for it > when they do not work however!) no, always make sure you have N+1 redundancy with a particular peer in dispersed locations. or N+2 if you can afford the capex. > peering on only one of them therefore does not make your network more > reliable in any way (it becomes a different story when you connect to like > 10 or so worldwide). > as for "peering" agreements, just implement an open peering policy > (doesn't nessesarily have to take place over an ix, also applies to pieces > of ethernet running from your network to others). > those basically are contracts that force anyone who has also signed one to > peer with your network, wether they like you or not (saves the trouble > when you are a content provider and others do not want to peer with you > because they provide content too and you are a competing party etc). you will find that most peering contracts or agreement have nice clauses to terminate the peering at some agreed notice, as well as a whole host of clauses that give the peering manager the power to say no if he feels so. > -- > HRH Sven Olaf Prinz von CyberBunker-Kamphuis, MP. > Minister of Telecommunications, Republic CyberBunker. ok, you're a troll and I bit... -- Pf
On Thu, Oct 30, 2008 at 01:03:55PM +0000, HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP wrote:
(the amsix with their many outages and connected parties that rely primarliy on it's functionality is a prime example here)
internet exchanges usually are some sort of hobby computer club, you cannot rely on them to actually -work-, but when they do work that's "nice" (always make sure you have enough paid capacity to cover for it when they do not work however!)
http://www.ams-ix.net/technical/stats/ certainly looks like over 500Gb/s of traffic across ams-ix. that's a big 'sort of hobby computer club'. i wonder what all those hobbiests are doing. in all seriousness, the above post is ludicrous. ams-ix runs one of the most reliable exchange platforms on the planet due to an incredible investment in optical switches and duplicate hardware. it's expensive to run that way but the results have been incredible. none of that is actually on-target for the original question about the *value* (other than cost savings) of peering. so far there have been some good values articulated and there may be more (reach, latency, diversity of path, diversity of capacity, control, flexibility, options, price negotation) and some additional costs have been mentioned (capex for peering routing, opex for the peering itself + cross connects + switch fees + additional time spent troubleshooting routing events). are there others?
Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited.
i was not an individual addressed but the attached mail was sent to a mailing list of 10k people. HRH Sven Olaf is in violation of his own policy about dissemination, distribution or copying. t. -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation todd@renesys.com http://www.renesys.com/blog
On Oct 30, 2008, at 10:49 AM, Todd Underwood wrote:
so far there have been some good values articulated and there may be more (reach, latency, diversity of path, diversity of capacity, control, flexibility, options, price negotation) and some additional costs have been mentioned (capex for peering routing, opex for the peering itself + cross connects + switch fees + additional time spent troubleshooting routing events).
are there others?
Almost certainly. But I'm sure the OP has a nice list to at least get him started of peering benefits. Interestingly, no one has mentioned the downside of peering. Just to play devil's advocate, allow me to mention some "cons" about peering: If you drop all peering and push traffic to transit providers, you can frequently get lower price per bit. Picking 2/3/4 transit providers and committing large amounts to them gives you flexibility, control, reliability, lowers your CapEx, and lowers your network complexity which can (should) lower your OpEx. There are others, but you get the point. Just be sure to consider everything when deciding whether to peer. -- TTFN, patrick P.S. Obviously, I think peering is better for the "network" I run, but that cannot and should not be generalized to every network on the Internet.
Hey Patrick... Thanks for playing devil's advocate... I am truly trying to cover both sides of the discussion - technically it's what we want for sure but the top of the food chain looks beyond just what a technical team wants to do as I'm sure we're all plagued by sometimes ... In our specific case, after factoring in ALL costs in an extensive analysis - transit and peering end up very close .. peering being a very slight amount above transit in our case. At the end of the day it's almost a moot point from a cost perspective (you can tell I'm not a bean counter lol) I would argue though that even with 4 transit providers (which we have now), that peering is an excellent venue to take on - even for the time/management involved. Of course that opinion I can only speak for our situation in that regard..;) Appreciate your input - and I agree though that peering isn't for everyone... definitely... Take care, Paul -----Original Message----- From: Patrick W. Gilmore [mailto:patrick@ianai.net] Sent: Thursday, October 30, 2008 12:15 PM To: NANOG list Subject: Re: Peering - Benefits? On Oct 30, 2008, at 10:49 AM, Todd Underwood wrote:
so far there have been some good values articulated and there may be more (reach, latency, diversity of path, diversity of capacity, control, flexibility, options, price negotation) and some additional costs have been mentioned (capex for peering routing, opex for the peering itself + cross connects + switch fees + additional time spent troubleshooting routing events).
are there others?
Almost certainly. But I'm sure the OP has a nice list to at least get him started of peering benefits. Interestingly, no one has mentioned the downside of peering. Just to play devil's advocate, allow me to mention some "cons" about peering: If you drop all peering and push traffic to transit providers, you can frequently get lower price per bit. Picking 2/3/4 transit providers and committing large amounts to them gives you flexibility, control, reliability, lowers your CapEx, and lowers your network complexity which can (should) lower your OpEx. There are others, but you get the point. Just be sure to consider everything when deciding whether to peer. -- TTFN, patrick P.S. Obviously, I think peering is better for the "network" I run, but that cannot and should not be generalized to every network on the Internet. ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
On Oct 30, 2008, at 12:38 PM, Paul Stewart wrote:
Thanks for playing devil's advocate... I am truly trying to cover both sides of the discussion - technically it's what we want for sure but the top of the food chain looks beyond just what a technical team wants to do as I'm sure we're all plagued by sometimes ...
In our specific case, after factoring in ALL costs in an extensive analysis - transit and peering end up very close .. peering being a very slight amount above transit in our case. At the end of the day it's almost a moot point from a cost perspective (you can tell I'm not a bean counter lol)
If it is break even, the "intangibles" of peering clearly make it a winner. Plus, as traffic increases, I bet the "cost" of peering goes down. And everyone's traffic is increasing.
I would argue though that even with 4 transit providers (which we have now), that peering is an excellent venue to take on - even for the time/management involved. Of course that opinion I can only speak for our situation in that regard..;)
Perhaps dropping to 3 or even 2 transit providers is in order when you start peering? That would allow you to give larger commits, reducing unit costs. You still have plenty of vectors if you can peer off a significant fraction of your traffic. For instance, lets say you can peer at least 25% of your traffic (a pretty modest amount). If you split your traffic evenly across four providers, this lets you drop one with no loss of redundancy. Plus you get all the other things peering is good for. -- TTFN, patrick
-----Original Message----- From: Patrick W. Gilmore [mailto:patrick@ianai.net] Sent: Thursday, October 30, 2008 12:15 PM To: NANOG list Subject: Re: Peering - Benefits?
On Oct 30, 2008, at 10:49 AM, Todd Underwood wrote:
so far there have been some good values articulated and there may be more (reach, latency, diversity of path, diversity of capacity, control, flexibility, options, price negotation) and some additional costs have been mentioned (capex for peering routing, opex for the peering itself + cross connects + switch fees + additional time spent troubleshooting routing events).
are there others?
Almost certainly.
But I'm sure the OP has a nice list to at least get him started of peering benefits. Interestingly, no one has mentioned the downside of peering. Just to play devil's advocate, allow me to mention some "cons" about peering: If you drop all peering and push traffic to transit providers, you can frequently get lower price per bit. Picking 2/3/4 transit providers and committing large amounts to them gives you flexibility, control, reliability, lowers your CapEx, and lowers your network complexity which can (should) lower your OpEx. There are others, but you get the point.
Just be sure to consider everything when deciding whether to peer.
-- TTFN, patrick
P.S. Obviously, I think peering is better for the "network" I run, but that cannot and should not be generalized to every network on the Internet.
Absolutely... I can see us dropping at least one of the transit providers over time - with current growth we might end up keeping all of them to meet needs though. Just depends on how fast traffic moves from transit to peering versus how quickly our overall requirements grow (pretty dramatic climb right now).... And yes, with our peering costs - the unit costs drop off considerably as they pick up so the longer term will be that peering will be considerably more economical than transit even with long haul costs... Cheers! Paul -----Original Message----- From: Patrick W. Gilmore [mailto:patrick@ianai.net] Sent: Thursday, October 30, 2008 1:06 PM To: NANOG list Subject: Re: Peering - Benefits? On Oct 30, 2008, at 12:38 PM, Paul Stewart wrote:
Thanks for playing devil's advocate... I am truly trying to cover both sides of the discussion - technically it's what we want for sure but the top of the food chain looks beyond just what a technical team wants to do as I'm sure we're all plagued by sometimes ...
In our specific case, after factoring in ALL costs in an extensive analysis - transit and peering end up very close .. peering being a very slight amount above transit in our case. At the end of the day it's almost a moot point from a cost perspective (you can tell I'm not a bean counter lol)
If it is break even, the "intangibles" of peering clearly make it a winner. Plus, as traffic increases, I bet the "cost" of peering goes down. And everyone's traffic is increasing.
I would argue though that even with 4 transit providers (which we have now), that peering is an excellent venue to take on - even for the time/management involved. Of course that opinion I can only speak for our situation in that regard..;)
Perhaps dropping to 3 or even 2 transit providers is in order when you start peering? That would allow you to give larger commits, reducing unit costs. You still have plenty of vectors if you can peer off a significant fraction of your traffic. For instance, lets say you can peer at least 25% of your traffic (a pretty modest amount). If you split your traffic evenly across four providers, this lets you drop one with no loss of redundancy. Plus you get all the other things peering is good for. -- TTFN, patrick
-----Original Message----- From: Patrick W. Gilmore [mailto:patrick@ianai.net] Sent: Thursday, October 30, 2008 12:15 PM To: NANOG list Subject: Re: Peering - Benefits?
On Oct 30, 2008, at 10:49 AM, Todd Underwood wrote:
so far there have been some good values articulated and there may be more (reach, latency, diversity of path, diversity of capacity, control, flexibility, options, price negotation) and some additional costs have been mentioned (capex for peering routing, opex for the peering itself + cross connects + switch fees + additional time spent troubleshooting routing events).
are there others?
Almost certainly.
But I'm sure the OP has a nice list to at least get him started of peering benefits. Interestingly, no one has mentioned the downside of peering. Just to play devil's advocate, allow me to mention some "cons" about peering: If you drop all peering and push traffic to transit providers, you can frequently get lower price per bit. Picking 2/3/4 transit providers and committing large amounts to them gives you flexibility, control, reliability, lowers your CapEx, and lowers your network complexity which can (should) lower your OpEx. There are others, but you get the point.
Just be sure to consider everything when deciding whether to peer.
-- TTFN, patrick
P.S. Obviously, I think peering is better for the "network" I run, but that cannot and should not be generalized to every network on the Internet.
---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
On Wed, Oct 29, 2008 at 03:28:04PM -0400, Valdis.Kletnieks@vt.edu wrote:
On Wed, 29 Oct 2008 15:17:45 EDT, Paul Stewart said:
I can think of some but looking to develop a concrete list of appealing reasons etc. such as:
-control over routing between networks -security aspect (being able to filter/verify routes to some degree) -latency/performance
I'm surprised you didn't include "chance to pick up a redundant connection". ...specifically, in non-carrier-owned colos you have a better chance of factoring out loop costs for pricing decisions.
A couple to add: - failure scoping: issues on a remote network can be better isolated from the rest of your traffic (or completely if it is the peer). - product variation: if you sell connectivity, a different/diverse/rich set of paths to offfer your downstreams is a win. -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE
Joe Provo wrote:
A couple to add: - failure scoping: issues on a remote network can be better isolated from the rest of your traffic (or completely if it is the peer).
Related to this is ability to contact the right people more quickly. If you've got a problem with/on someone's network then typically you can call their NOC directly. Compared with having to bounce through your transit providers helpdesk, who then escalate to their NOC, to the other NOC etc. This right is usually enshrined in most people's peering policy requirements. It's a powerful thing and not to be underestimated. MMC
This is probably going to be a somewhat unpopular opinion, mostly because people cannot figure out their COGS. If you can get transit for cheaper than your COGS, you are better off buying transit and not peering. There are some small arguments to be made for latency and 'cheap/free' peering if you are already buying transit at an exchange and your port/xconn fee is cheaper than your capital/opex for the amount of traffic you peer off. To be completely realistic, at current transit pricing, you are almost always better off just buying transit from two upstreams and calling it done, especially if you are posting to nanog asking about peering. /vijay On Wed, Oct 29, 2008 at 12:17 PM, Paul Stewart <pstewart@nexicomgroup.net> wrote:
Hi there...
I'm in a meeting next week to discuss settlement-free peering etc..... always an interesting time. A push is on (by myself) to get into other physical locations and participate on the peering exchanges.
Besides costs, what other factors are benefits to peering?
I can think of some but looking to develop a concrete list of appealing reasons etc. such as:
-control over routing between networks -security aspect (being able to filter/verify routes to some degree) -latency/performance
Just looking for other positive ideas etc...;)
Cheers!
Paul
----------------------------------------------------------------------------
"The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
As with all things, this isn't so cut and dried as everyone makes it seem. The OP was asking for an easy answer to a complex question, which usually shows a lack of understanding of the issues, or is an attempt to provoke controversy. So far, most of the discussion has focused on peering as a substitute for transit. The idea behind peering is not that the peer takes your traffic destined for other networks, but that you each deliver the traffic destined for each other directly, without the need to transit. This should save BOTH of you $ on transit, reduce routing complexity for the peered networks, make troubleshooting traffic issues between the networks easier, and improve user experience. Common examples of where peering makes a lot of sense are: Major hosting providers to major national end-user networks. CDNs to end-user networks. Local data centers and DR facilities to metropolitan Ethernet providers. Hosting facilities to networks that service certain specific user communities, such as local realty MLS systems to the local cable and DSL providers. If you're using peering for transit, you're kind of missing the point, and introducing a lot of potential network (route leakage or excessive route prepends) and business (at what point does a transit imbalance become unfair) problems. IMO, peer for direct delivery, use transit for all else. YMMV
-----Original Message----- From: vijay gill [mailto:vgill@vijaygill.com] Sent: Thursday, October 30, 2008 7:20 PM To: Paul Stewart Cc: nanog@nanog.org Subject: Re: Peering - Benefits?
This is probably going to be a somewhat unpopular opinion, mostly because people cannot figure out their COGS. If you can get transit for cheaper than your COGS, you are better off buying transit and not peering. There are some small arguments to be made for latency and 'cheap/free' peering if you are already buying transit at an exchange and your port/xconn fee is cheaper than your capital/opex for the amount of traffic you peer off.
To be completely realistic, at current transit pricing, you are almost always better off just buying transit from two upstreams and calling it done, especially if you are posting to nanog asking about peering.
/vijay
On Wed, Oct 29, 2008 at 12:17 PM, Paul Stewart <pstewart@nexicomgroup.net> wrote:
Hi there...
I'm in a meeting next week to discuss settlement-free peering etc..... always an interesting time. A push is on (by myself) to get into other physical locations and participate on the peering exchanges.
Besides costs, what other factors are benefits to peering?
I can think of some but looking to develop a concrete list of appealing reasons etc. such as:
-control over routing between networks -security aspect (being able to filter/verify routes to some degree) -latency/performance
Just looking for other positive ideas etc...;)
Cheers!
Paul
------
"The information transmitted is intended only for the person or
entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
There was no attempt to provoke controversy - I'm in the OP in this... there have been many replies that don't relate to my question though... I don't believe I have a lack of understanding neither - we do smaller scale peering today. I was however trying to look for positive and negative reasons for peering that perhaps we didn't take into consideration beyond how we do it today... the only change for our peering will be the element of long hauling the traffic and expanding it into larger scales - that's about it. Basically I have all the answers I'm looking for now - thank you. Paul -----Original Message----- From: Tomas L. Byrnes [mailto:tomb@byrneit.net] Sent: October 30, 2008 10:34 PM To: vijay gill; Paul Stewart Cc: nanog@nanog.org Subject: RE: Peering - Benefits? As with all things, this isn't so cut and dried as everyone makes it seem. The OP was asking for an easy answer to a complex question, which usually shows a lack of understanding of the issues, or is an attempt to provoke controversy. ---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
Why does the controversy word keep coming up? You're the third person now to ask if I was trying to provide controversy and for the third time , NO I AM NOT. And again, I *do* understand the issues at hand - although some new viewpoints I hadn't considered before came up and thank you. My question should have read specifically - "what points do you make with senior management to move towards larger, more diverse peering options compared to today?" Thank you however - I do have all the info I require and we're moving ahead... Best regards, Paul -----Original Message----- From: Tomas L. Byrnes [mailto:tomb@byrneit.net] Sent: Thursday, October 30, 2008 10:34 PM To: vijay gill; Paul Stewart Cc: nanog@nanog.org Subject: RE: Peering - Benefits? As with all things, this isn't so cut and dried as everyone makes it seem. The OP was asking for an easy answer to a complex question, which usually shows a lack of understanding of the issues, or is an attempt to provoke controversy. So far, most of the discussion has focused on peering as a substitute for transit. The idea behind peering is not that the peer takes your traffic destined for other networks, but that you each deliver the traffic destined for each other directly, without the need to transit. This should save BOTH of you $ on transit, reduce routing complexity for the peered networks, make troubleshooting traffic issues between the networks easier, and improve user experience. Common examples of where peering makes a lot of sense are: Major hosting providers to major national end-user networks. CDNs to end-user networks. Local data centers and DR facilities to metropolitan Ethernet providers. Hosting facilities to networks that service certain specific user communities, such as local realty MLS systems to the local cable and DSL providers. If you're using peering for transit, you're kind of missing the point, and introducing a lot of potential network (route leakage or excessive route prepends) and business (at what point does a transit imbalance become unfair) problems. IMO, peer for direct delivery, use transit for all else. YMMV
-----Original Message----- From: vijay gill [mailto:vgill@vijaygill.com] Sent: Thursday, October 30, 2008 7:20 PM To: Paul Stewart Cc: nanog@nanog.org Subject: Re: Peering - Benefits?
This is probably going to be a somewhat unpopular opinion, mostly because people cannot figure out their COGS. If you can get transit for cheaper than your COGS, you are better off buying transit and not peering. There are some small arguments to be made for latency and 'cheap/free' peering if you are already buying transit at an exchange and your port/xconn fee is cheaper than your capital/opex for the amount of traffic you peer off.
To be completely realistic, at current transit pricing, you are almost always better off just buying transit from two upstreams and calling it done, especially if you are posting to nanog asking about peering.
/vijay
On Wed, Oct 29, 2008 at 12:17 PM, Paul Stewart <pstewart@nexicomgroup.net> wrote:
Hi there...
I'm in a meeting next week to discuss settlement-free peering etc..... always an interesting time. A push is on (by myself) to get into other physical locations and participate on the peering exchanges.
Besides costs, what other factors are benefits to peering?
I can think of some but looking to develop a concrete list of appealing reasons etc. such as:
-control over routing between networks -security aspect (being able to filter/verify routes to some degree) -latency/performance
Just looking for other positive ideas etc...;)
Cheers!
Paul
------
"The information transmitted is intended only for the person or
entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
On Oct 31, 2008, at 12:56 PM, Paul Stewart wrote:
Why does the controversy word keep coming up? You're the third person now to ask if I was trying to provide controversy and for the third time , NO I AM NOT.
And again, I *do* understand the issues at hand - although some new viewpoints I hadn't considered before came up and thank you.
My question should have read specifically - "what points do you make with senior management to move towards larger, more diverse peering options compared to today?"
Refer them to the Cogent / Sprint thread also occurring on NANOG. (I know it is too late to enter but I thought this was too apropos to pass up.) Regards Marshall
Thank you however - I do have all the info I require and we're moving ahead...
Best regards,
Paul
-----Original Message----- From: Tomas L. Byrnes [mailto:tomb@byrneit.net] Sent: Thursday, October 30, 2008 10:34 PM To: vijay gill; Paul Stewart Cc: nanog@nanog.org Subject: RE: Peering - Benefits?
As with all things, this isn't so cut and dried as everyone makes it seem. The OP was asking for an easy answer to a complex question, which usually shows a lack of understanding of the issues, or is an attempt to provoke controversy.
So far, most of the discussion has focused on peering as a substitute for transit.
The idea behind peering is not that the peer takes your traffic destined for other networks, but that you each deliver the traffic destined for each other directly, without the need to transit.
This should save BOTH of you $ on transit, reduce routing complexity for the peered networks, make troubleshooting traffic issues between the networks easier, and improve user experience.
Common examples of where peering makes a lot of sense are:
Major hosting providers to major national end-user networks.
CDNs to end-user networks.
Local data centers and DR facilities to metropolitan Ethernet providers.
Hosting facilities to networks that service certain specific user communities, such as local realty MLS systems to the local cable and DSL providers.
If you're using peering for transit, you're kind of missing the point, and introducing a lot of potential network (route leakage or excessive route prepends) and business (at what point does a transit imbalance become unfair) problems.
IMO, peer for direct delivery, use transit for all else.
YMMV
-----Original Message----- From: vijay gill [mailto:vgill@vijaygill.com] Sent: Thursday, October 30, 2008 7:20 PM To: Paul Stewart Cc: nanog@nanog.org Subject: Re: Peering - Benefits?
This is probably going to be a somewhat unpopular opinion, mostly because people cannot figure out their COGS. If you can get transit for cheaper than your COGS, you are better off buying transit and not peering. There are some small arguments to be made for latency and 'cheap/free' peering if you are already buying transit at an exchange and your port/xconn fee is cheaper than your capital/opex for the amount of traffic you peer off.
To be completely realistic, at current transit pricing, you are almost always better off just buying transit from two upstreams and calling it done, especially if you are posting to nanog asking about peering.
/vijay
On Wed, Oct 29, 2008 at 12:17 PM, Paul Stewart <pstewart@nexicomgroup.net> wrote:
Hi there...
I'm in a meeting next week to discuss settlement-free peering etc..... always an interesting time. A push is on (by myself) to get into other physical locations and participate on the peering exchanges.
Besides costs, what other factors are benefits to peering?
I can think of some but looking to develop a concrete list of appealing reasons etc. such as:
-control over routing between networks -security aspect (being able to filter/verify routes to some degree) -latency/performance
Just looking for other positive ideas etc...;)
Cheers!
Paul
------
"The information transmitted is intended only for the person or
entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
----------------------------------------------------------------------------
"The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
On 31 Oct 2008, at 16:56, Paul Stewart wrote:
Why does the controversy word keep coming up? You're the third personnow to ask if I was trying to provide controversy and for the third time, NO I AM NOT.
Hi, I have no intention of fanning the fire, but I can explain the controversy message pretty well. Bringing a whole new methodology to how an organisation interconnects is hugely controversial for most organisations who are not already peering. In my role as a consulting engineer in this field, I most recall introducing peering to two 'enterprise' organisations. Both joined exchanges in Europe at a time when their network edge was redesigned to support 'better practice' IT. Both were e-commerce organisations who traded directly with the general public, and ran open peering policies soliciting sessions with eyeball networks. At the end of my involvement with both, each organisation was peering off a third or so of their traffic. One is still peering and probably peers off more traffic. The other withdrew from peering operations after around six months. Wearing another hat as an IX operator, I can confirm that IXPs do not want organisations to join and leave, since most of the IXP costs are front- stacked and relate to setup. So what went wrong ? The organisation which is still peering has a more rich technical culture, willing to accept the so-called intangible benefits of peering. The second asked "are we a sales and marketing firm designed to shift widgets, or are we a fancy technical firm with a big network ?" The culture of many firms is to keep-it-simple-stupid, and if your proposal for peering reached C*O levels, then it would be met with significant controversy if you are not already peering. Especially when the C*O responsible for legal hears about peering contracts... Furthermore, to get and retain the peers you need, you need to make relationships with other peering co-ordinators. Attending the peering conferences is hard work and all of your colleagues will think you're on a jolly ! If you can't get sponsorship for your idea outside the technology department, then the idea is probably dead. Are there some PNIs you can run in the local area which will have a significant impact on your resiliency and traffic profile ? Good luck. I am happy to talk to you in more detail about this subject if you would like more advice, drop me a line off-list. Best wishes Andy Davidson.
On 31 Oct 2008, at 16:56, Paul Stewart wrote:
Why does the controversy word keep coming up? You're the third personnow to ask if I was trying to provide controversy and for the third time, NO I AM NOT.
Hi, I have no intention of fanning the fire, but I can explain the controversy message pretty well. Bringing a whole new methodology to how an organisation interconnects is hugely controversial for most organisations who are not already peering. In my role as a consulting engineer in this field, I most recall introducing peering to two 'enterprise' organisations. Both joined exchanges in Europe at a time when their network edge was redesigned to support 'better practice' IT. Both were e-commerce organisations who traded directly with the general public, and ran open peering policies soliciting sessions with eyeball networks. At the end of my involvement with both, each organisation was peering off a third or so of their traffic. One is still peering and probably peers off more traffic. The other withdrew from peering operations after around six months. Wearing another hat as an IX operator, I can confirm that IXPs do not want organisations to join and leave, since most of the IXP costs are front- stacked and relate to setup. So what went wrong ? The organisation which is still peering has a more rich technical culture, willing to accept the so-called intangible benefits of peering. The second asked "are we a sales and marketing firm designed to shift widgets, or are we a fancy technical firm with a big network ?" The culture of many firms is to keep-it-simple-stupid, and if your proposal for peering reached C*O levels, then it would be met with significant controversy if you are not already peering. Especially when the C*O responsible for legal hears about peering contracts... Furthermore, to get and retain the peers you need, you need to make relationships with other peering co-ordinators. Attending the peering conferences is hard work and all of your colleagues will think you're on a jolly ! If you can't get sponsorship for your idea outside the technology department, then the idea is probably dead. Are there some PNIs you can run in the local area which will have a significant impact on your resiliency and traffic profile ? Good luck. I am happy to talk to you in more detail about this subject if you would like more advice, drop me a line off-list. Best wishes Andy Davidson.
On Oct 30, 2008, at 10:19 PM, vijay gill wrote:
This is probably going to be a somewhat unpopular opinion, mostly because people cannot figure out their COGS. If you can get transit for cheaper than your COGS, you are better off buying transit and not peering. There are some small arguments to be made for latency and 'cheap/free' peering if you are already buying transit at an exchange and your port/xconn fee is cheaper than your capital/opex for the amount of traffic you peer off.
One of us is confused. Transit is _part_ of COGS, at least for most of the group reading this list. Finding transit "cheaper than your COGS" just means cheaper than you get it now. And that in no way way means you should dump peering. What if peering is cheaper than transit? The part where we do agree is that most people cannot figure out their COGS. And you might even convince me that "you don't know what peering really costs you" is a valid reason to shy away from it. But that is not what you said. Assuming you can figure your actual costs, and peering is at least break even with transit, I would suggest you peer. If peering is not cheaper, then I would suggest not doing it. (Obviously a generalization - there are corner cases which go against the rule.) And if you cannot figure your actual costs, it is much safer to stick with the more simple solution - i.e. transit.
To be completely realistic, at current transit pricing, you are almost always better off just buying transit from two upstreams and calling it done, especially if you are posting to nanog asking about peering.
That is a pretty broad statement. Not that I think you are wrong.... I honestly am not sure at this point. (Mostly 'cause I'm not sure who would e-mail NANOG asking about it. :-) -- TTFN, patrick
On Wed, Oct 29, 2008 at 12:17 PM, Paul Stewart <pstewart@nexicomgroup.net> wrote:
Hi there...
I'm in a meeting next week to discuss settlement-free peering etc..... always an interesting time. A push is on (by myself) to get into other physical locations and participate on the peering exchanges.
Besides costs, what other factors are benefits to peering?
I can think of some but looking to develop a concrete list of appealing reasons etc. such as:
-control over routing between networks -security aspect (being able to filter/verify routes to some degree) -latency/performance
Just looking for other positive ideas etc...;)
Cheers!
Paul
----------------------------------------------------------------------------
"The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
On Thu, Oct 30, 2008 at 9:41 PM, Patrick W. Gilmore <patrick@ianai.net> wrote:
On Oct 30, 2008, at 10:19 PM, vijay gill wrote:
This is probably going to be a somewhat unpopular opinion, mostly because people cannot figure out their COGS. If you can get transit for cheaper than your COGS, you are better off buying transit and not peering. There are some small arguments to be made for latency and 'cheap/free' peering if you are already buying transit at an exchange and your port/xconn fee is cheaper than your capital/opex for the amount of traffic you peer off.
One of us is confused.
precisely.
Transit is _part_ of COGS, at least for most of the group reading this list. Finding transit "cheaper than your COGS" just means cheaper than you get it now. And that in no way way means you should dump peering. What if peering is cheaper than transit?
Cost of transport, opex and capital to build out to a peering point, ports for interconnect, vs the expected money saved by peering away sufficient traffic is the analysis that will inform your strategy. This is why I said if you are already at a place where you are buying transit, it probably worth it to peer with the folks locally. The point is if you are building out specifically to peer, the effort is not worth it if you are not operating at scale, and if you are operating at scale, you are not going to ask nanog about peering. /vijay
The part where we do agree is that most people cannot figure out their COGS. And you might even convince me that "you don't know what peering really costs you" is a valid reason to shy away from it. But that is not what you said.
Assuming you can figure your actual costs, and peering is at least break even with transit, I would suggest you peer. If peering is not cheaper, then I would suggest not doing it. (Obviously a generalization - there are corner cases which go against the rule.) And if you cannot figure your actual costs, it is much safer to stick with the more simple solution - i.e. transit.
To be completely realistic, at current transit pricing, you are almost always better off just buying transit from two upstreams and calling it done, especially if you are posting to nanog asking about peering.
That is a pretty broad statement.
Not that I think you are wrong.... I honestly am not sure at this point. (Mostly 'cause I'm not sure who would e-mail NANOG asking about it. :-)
-- TTFN, patrick
On Wed, Oct 29, 2008 at 12:17 PM, Paul Stewart <pstewart@nexicomgroup.net> wrote:
Hi there...
I'm in a meeting next week to discuss settlement-free peering etc..... always an interesting time. A push is on (by myself) to get into other physical locations and participate on the peering exchanges.
Besides costs, what other factors are benefits to peering?
I can think of some but looking to develop a concrete list of appealing reasons etc. such as:
-control over routing between networks -security aspect (being able to filter/verify routes to some degree) -latency/performance
Just looking for other positive ideas etc...;)
Cheers!
Paul
----------------------------------------------------------------------------
"The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
The point is if you are building out specifically to peer, the effort is not worth it if you are not operating at scale, ^ probably
i can think of situations where there may be very low cost to build-out to peer. but they are unusual.
and if you are operating at scale, you are not going to ask nanog about peering.
bingo! ( unless you're a shill being paid to give us old dogs an excuse to pontificate :) randy
On Oct 31, 2008, at 1:05 AM, vijay gill wrote:
On Thu, Oct 30, 2008 at 9:41 PM, Patrick W. Gilmore <patrick@ianai.net> wrote:
On Oct 30, 2008, at 10:19 PM, vijay gill wrote:
This is probably going to be a somewhat unpopular opinion, mostly because people cannot figure out their COGS. If you can get transit for cheaper than your COGS, you are better off buying transit There are some small arguments to be made for latency and 'cheap/free' peering if you are already buying transit at an exchange and your port/xconn fee is cheaper than your capital/opex for the amount of traffic you peer off.
One of us is confused.
precisely.
Well, I could also be confused, which would make two of us. But I will agree with you here and say precisely one.
Transit is _part_ of COGS, at least for most of the group reading this list. Finding transit "cheaper than your COGS" just means cheaper than you get it now. And that in no way way means you should dump peering. What if peering is cheaper than transit?
Cost of transport, opex and capital to build out to a peering point, ports for interconnect, vs the expected money saved by peering away sufficient traffic is the analysis that will inform your strategy. This is why I said if you are already at a place where you are buying transit, it probably worth it to peer with the folks locally.
None of that is in question. However, you also said: "If you can get transit for cheaper than your COGS, you are better off buying transit and not peering." So either you were confused, or .. well, let's be generous and say you were confused. :-) I'm glad you have cleared your confusion. -- TTFN, patrick
On Thu, Oct 30, 2008 at 10:13 PM, Patrick W. Gilmore <patrick@ianai.net> wrote:
On Oct 31, 2008, at 1:05 AM, vijay gill wrote:
On Thu, Oct 30, 2008 at 9:41 PM, Patrick W. Gilmore <patrick@ianai.net> wrote:
On Oct 30, 2008, at 10:19 PM, vijay gill wrote:
This is probably going to be a somewhat unpopular opinion, mostly because people cannot figure out their COGS. If you can get transit for cheaper than your COGS, you are better off buying transit There are some small arguments to be made for latency and 'cheap/free' peering if you are already buying transit at an exchange and your port/xconn fee is cheaper than your capital/opex for the amount of traffic you peer off.
One of us is confused.
precisely.
Well, I could also be confused, which would make two of us. But I will agree with you here and say precisely one.
Transit is _part_ of COGS, at least for most of the group reading this list. Finding transit "cheaper than your COGS" just means cheaper than you get it now. And that in no way way means you should dump peering. What if peering is cheaper than transit?
Cost of transport, opex and capital to build out to a peering point, ports for interconnect, vs the expected money saved by peering away sufficient traffic is the analysis that will inform your strategy. This is why I said if you are already at a place where you are buying transit, it probably worth it to peer with the folks locally.
None of that is in question. However, you also said: "If you can get transit for cheaper than your COGS, you are better off buying transit and not peering." So either you were confused, or .. well, let's be generous and say you were confused. :-)
I'm glad you have cleared your confusion.
Yeah, I was using COGs as a shorthand for cost to build out to peering locations, I should have really further broken it down into specific cases. /vijay
-- TTFN, patrick
Hi there... We've done the financial study and we've taken great lengths in netflow analysis to do estimated traffic flows at each peering location etc. This was factored before I posted and as I mentioned in an earlier posting - the cost element is pretty much addressed already with our transit/peering coming in almost at the same cost when the built-out is completed. We are already peering locally with the folks where most of our transit comes from - been doing that for quite a period of time...
Cost of transport, opex and capital to build out to a peering point, ports for interconnect, vs the expected money saved by peering away sufficient traffic is the analysis that will inform your strategy. This is why I said if you are already at a place where you are buying transit, it probably worth it to peer with the folks locally.
My question was meant at a much higher level - a level where costs are equal for peering/transit and all the "technical" and the "financial" homework has been done already.... now I'm the stage of one last meeting with top level management to explain "peering" and it's magic. These are mainly non-technical people - so my question to NANOG was for viewpoints on peering of which hopefully I could reinforce some of my own thoughts with. Whether or not someone operating at scale isn't the discussion - and it's funny how many people involved with companies (that are "operating at scale") have emailed me offline since this discussion started a few days ago with questions/thoughts and strategy.
The point is if you are building out specifically to peer, the effort is not worth it if you are not operating at scale, and if you are operating at scale, you are not going to ask nanog about peering.
---------------------------------------------------------------------------- "The information transmitted is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. If you received this in error, please contact the sender immediately and then destroy this transmission, including all attachments, without copying, distributing or disclosing same. Thank you."
"Paul Stewart" <pstewart@nexicomgroup.net> writes:
...
My question was meant at a much higher level - a level where costs are equal for peering/transit and all the "technical" and the "financial" homework has been done already.... now I'm the stage of one last meeting with top level management to explain "peering" and it's magic. These are mainly non-technical people - so my question to NANOG was for viewpoints on peering of which hopefully I could reinforce some of my own thoughts with. Whether or not someone operating at scale isn't the discussion - and it's funny how many people involved with companies (that are "operating at scale") have emailed me offline since this discussion started a few days ago with questions/thoughts and strategy.
if the financials and technicals are similar enough to be factored out, then what you have to look at is possible variance between tactical and strategic cost/benefit ratios. basically this boils down to the cost of lock-in. if you're going to avoid lock-in then you have get your own address space and build out to at least one IXP and then, buy diverse transit. once you have done all that, the cost of also peering is in the noise, whereas the advantage of also peering is noticeable if not always easily measureable. if you're not going to avoid lock-in, then everything you'd need to spend to avoid it can be avoided, and you won't be peering unless it's for purely strategic reasons. -- Paul Vixie
My company will be peering with two other SPs in the area purely for business strategic purposes. It turns out that at least one of these SPs owns the fiber running to the first CO in our transit back to Chicago. So it helps to be buddies with these companies. Paul Vixie wrote:
"Paul Stewart" <pstewart@nexicomgroup.net> writes:
...
My question was meant at a much higher level - a level where costs are equal for peering/transit and all the "technical" and the "financial" homework has been done already.... now I'm the stage of one last meeting with top level management to explain "peering" and it's magic. These are mainly non-technical people - so my question to NANOG was for viewpoints on peering of which hopefully I could reinforce some of my own thoughts with. Whether or not someone operating at scale isn't the discussion - and it's funny how many people involved with companies (that are "operating at scale") have emailed me offline since this discussion started a few days ago with questions/thoughts and strategy.
if the financials and technicals are similar enough to be factored out, then what you have to look at is possible variance between tactical and strategic cost/benefit ratios. basically this boils down to the cost of lock-in. if you're going to avoid lock-in then you have get your own address space and build out to at least one IXP and then, buy diverse transit. once you have done all that, the cost of also peering is in the noise, whereas the advantage of also peering is noticeable if not always easily measureable. if you're not going to avoid lock-in, then everything you'd need to spend to avoid it can be avoided, and you won't be peering unless it's for purely strategic reasons.
-- Steve King Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional
vijay gill writes:
This is probably going to be a somewhat unpopular opinion, mostly because people cannot figure out their COGS. If you can get transit for cheaper than your COGS, you are better off buying transit and not peering. There are some small arguments to be made for latency and 'cheap/free' peering if you are already buying transit at an exchange and your port/xconn fee is cheaper than your capital/opex for the amount of traffic you peer off.
The other factor worth considering is the level of control your business plan supports giving up to third parties. This is more of a problem for things like real-time voice or video, but the circumstance can exist that depending on two even very good carriers may be uncomfortable - particular the first time one of them has a systemic issue.
To be completely realistic, at current transit pricing, you are almost always better off just buying transit from two upstreams and calling it done, especially if you are posting to nanog asking about peering.
Yep. Joe
participants (20)
-
Adam Armstrong -
Andy Davidson -
HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP -
Joe Malcolm -
Joe Provo -
Marshall Eubanks -
Matthew Moyle-Croft -
michael.dillon＠bt.com -
Miquel van Smoorenburg -
Patrick W. Gilmore -
Paul Stewart -
Paul Vixie -
Pierfrancesco Caci -
Randy Bush -
Steven King -
Todd Underwood -
Tomas L. Byrnes -
Valdis.Kletnieks＠vt.edu -
vijay gill -
Will Hargrave