Re: Another driver for v6?
On Wed, 29 Oct 2008, David W. Hankins wrote: On Wed, Oct 29, 2008 at 06:32:31PM -0400, Steven King wrote: Does anyone see any benefits to beginning a small deployment of IPv6 now even if its just for internal usage? It is almost lunacy to deploy IPv6 in a customer-facing sense (note for example Google's choice to put its on a separate FQDN). At Could you please elaborate on this point? My data presented http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg01582.html indicates that there are very very few (the longer I collected the data, the better the ratio got) who cannot properly fetch a resource that has A/. this point, I'd say people are still trying to figure out how clients will migrate to IPv6. Which seems like a pretty bad time to still be trying to figure that out, but ohwell. 6to4 and Teredo traffic is increasing very rapidly, so that seems to be one path taken right now: http://ipv6.tele2.net/mrtg/total.html (We have all our IPv6 related stats and info on http://ipv6.tele2.net/) But yes, how to get native to residential users is still not hammered out. And of course you need to run your own dog food on internal LANs before you start telling customers these IPv6 address thingies are useful. Quite, I think OSS/BSS is going to be a bigger challenge than actually moving the IPv6 packets. IPv6: It's kind of like storing dry food in preparation for the apocalypse. If you actually KNOW the apocalypse is coming (but not when), this is correct. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Peering - Benefits?
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
RE: Another driver for v6?
Does anyone see any benefits to beginning a small deployment of IPv6 now even if its just for internal usage? According to http://www.getipv6.info/index.php/First_Steps_for_ISPs you should deploy some IPv6 transition technology to make sure that your network does not cause problems for the growing number of your customers who are already using IPv6. Of course, getting up to speed on IPv6 is also a worthy goal especially since it enables you to move much more quickly if IPv6 takes off suddenly. --Michael Dillon
Re: Another driver for v6?
On 30/10/08 07:10, Mikael Abrahamsson wrote: On Wed, 29 Oct 2008, David W. Hankins wrote: On Wed, Oct 29, 2008 at 06:32:31PM -0400, Steven King wrote: Does anyone see any benefits to beginning a small deployment of IPv6 now even if its just for internal usage? It is almost lunacy to deploy IPv6 in a customer-facing sense (note for example Google's choice to put its on a separate FQDN). At Could you please elaborate on this point? My data presented http://www.ops.ietf.org/lists/v6ops/v6ops.2008/msg01582.html indicates that there are very very few (the longer I collected the data, the better the ratio got) who cannot properly fetch a resource that has A/. Your stats (which are very interesting btw, thanks for doing the work) suggest that the number of clients that would make use of the record for a dual-stack service is about the same as the number of clients that would fail in the event that both A and were present. That's not exactly an incentive to content providers is it? IPv6: It's kind of like storing dry food in preparation for the apocalypse. If you actually KNOW the apocalypse is coming (but not when), this is correct. The end is nigh - http://penrose.uk6x.com/ Mat
RE: Another driver for v6?
It is almost lunacy to deploy IPv6 in a customer-facing sense (note for example Google's choice to put its on a separate FQDN). If you're going to use emotionally charged language then don't shoot yourself in the foot by using such an illogical and contrary example. Google is a very big network-oriented company and they have indeed deployed IPv6 in a customer-facing sense. To follow in their footsteps is not lunacy. They have shown that when you have a large distributed load-sharing platform, it is perfectly safe to deploy IPv6 as an alternate service entry point, in the same way that they have mail.google.com and docs.google as separate service entry points. Most people who are urging ISPs to deploy IPv6 are not telling them to do stupid things like run out and add records to all their domain names. We are telling people to trial and test IPv6 in the lab, and then roll out specific targeted IPv6 services like a 6to4 relay. Above all, don't be a lunatic, and do educate yourself and your staff before you make a move. IPv6 deployment is not a greenfield deployment so you have to weave it into the fabric of your own unique network architecture. That requires understanding of IPv6 which you can only get by trying it out yourself in your lab environment. At this point, I'd say people are still trying to figure out how clients will migrate to IPv6. That is a pretty dumb thing to do. Clients have already migrated to IPv6 years ago using the technology given to them by Apple, Microsoft and the free UNIXes. Job 1 is to support those clients. Job 2 is to figure out how you can deploy IPv6 at your network edge in such a way that you can grow the edge without consuming IPv4 addresses. For many small and mid-size ISPs, Job 2 does not involve anything to do with the customer's modem device because you don't have the kind of relationship with modem vendors to influence their product development. So focus on your own network edge, not on your customers' network edges. It is at this time more a question of strategic positioning. The kind of thing your boss should be thinking about. Bosses really appreciate well-reasoned white papers with a clear and straightforward management summary on the first page. Do you have the information and understanding of IPv6 in order to write such a white paper? Switching your management network to IPv6 single-stack This may actually be the last and toughest thing that ISPs do because of the variety of software and stuff in the management network. --Michael Dillon
Re: Another driver for v6?
On Thu, 30 Oct 2008, Matthew Ford wrote: Your stats (which are very interesting btw, thanks for doing the work) suggest that the number of clients that would make use of the record for a dual-stack service is about the same as the number of clients that would fail in the event that both A and were present. That's not exactly an incentive to content providers is it? The last couple of days the ratio went down to less than 0.3% who would potentially get in trouble (factor is most likely less as the measurement method penalises later objects). But yes, there is absolutely no upside to deploying IPv6 for content providers in the short term. It's like Y2K, there was NO upside to fixing it until December 31 1999. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
RE: Peering - Benefits?
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:[EMAIL PROTECTED] Sent: Thursday, October 30, 2008 9:04 AM To: Paul Stewart Cc: [EMAIL PROTECTED]; 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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.
Re: Peering - Benefits?
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.
Re: Peering - Benefits?
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
Re: Peering - Benefits?
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:[EMAIL PROTECTED] Sent: October 29, 2008 6:22 PM To: Paul Stewart Cc: [EMAIL PROTECTED]; 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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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.
Re: Peering - Benefits?
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
Re: Peering - Benefits?
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.
Re: Peering - Benefits?
:- HRH == HRH Sven Olaf Prinz von CyberBunker-Kamphuis MP [EMAIL PROTECTED] 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
Re: Peering - Benefits?
On Thu, Oct 30, 2008 at 01:03:55PM +, 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 [EMAIL PROTECTED] http://www.renesys.com/blog
Re: Another driver for v6?
On 30 Oct 2008, at 15:47, David W. Hankins wrote: If someone can't reach the hypothetical A/ www.google.com RRset, you've just increased your support costs. My network is slow. Are you using IPv4 or IPv6? Netscape. Do you think that industry should be working to some kind of well supported / worldwide flag day when lots of popular resources add v6 records at the same time ? In the same way that in the UK, appliance manufacturers have been educating people about the analogue terrestrial TV switchoff by 2012, do you think that we should be advocating a 'internet PLUS day' some time in (date plucked from the air) 2014 ? -a
RE: Another driver for v6?
In the same way that in the UK, appliance manufacturers have been educating people about the analogue terrestrial TV switchoff by 2012, do you think that we should be advocating a 'internet PLUS day' some time in (date plucked from the air) 2014 ? Actually, the Internet PLUS day should be tied to some other event, say the London 2012 Olympics. That would be a kind of launch event for a lot of people to make IPv6 services available. Then, a few years after this, we could have an Internet version 4 eulogy event and get a lot of ISPs to shut off legacy IPv4 services. That would have to be 2016 or later and it wouldn't be like the analog TV shutoff, because it would not be a 100% shutoff. I think that technical people underestimate the impact that this type of an event can provide. While we want to avoid being forced into a flag-day switchover, that does not mean that a flag day is all bad. We could have the Internet PLUS flag day in order to raise awareness and give ISPs a target to shoot for. --Michael Dillon
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.
Re: Another driver for v6?
[EMAIL PROTECTED] wrote: I think that technical people underestimate the impact that this type of an event can provide. While we want to avoid being forced into a flag-day switchover, that does not mean that a flag day is all bad. We could have the Internet PLUS flag day in order to raise awareness and give ISPs a target to shoot for. This new internet is brought to you by Pepsi: the choice a new version! or maybe IPv6 tastes good, like an Internet should or, oh never mind :) Mike --Michael Dillon
Re: Another driver for v6?
On Thu, 30 Oct 2008, David W. Hankins wrote: I don't know how to ask this question without sounding mean, but did the graph spike out of zero, or did you start collecting two months ago? It spiked out of zero as we put up our 6to4 and teredo relays approx two months ago. I don't know where the traffic was before, probably at other peoples 6to4 relays. -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Another driver for v6?
On Thu, 30 Oct 2008 15:55:01 -, Andy Davidson said: In the same way that in the UK, appliance manufacturers have been educating people about the analogue terrestrial TV switchoff by 2012, Is your side of the pond any more ready than our side is for next Febuary's drop-dead cutoff? pgpEwSKfUqIER.pgp Description: PGP signature
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:[EMAIL PROTECTED] 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.
RE: Peering - Benefits?
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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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.
Sprint / Cogent
Looks like maybe Sprint and Cogent are experiencing communications difficulties in the DC (and probably other) areas. Theories include a potential depeering. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Sprint / Cogent
On Oct 30, 2008, at 6:08 PM, Joe Greco wrote: Looks like maybe Sprint and Cogent are experiencing communications difficulties in the DC (and probably other) areas. Theories include a potential depeering. Not a theory. -- TTFN, patrick
Re: Sprint / Cogent
On Oct 30, 2008, at 6:08 PM, Joe Greco wrote: Looks like maybe Sprint and Cogent are experiencing communications difficulties in the DC (and probably other) areas. Theories include a potential depeering. I am seeing issues Cogent - Sprint at Tyco Road, Tysons Corner VA. arin_whois 206.159.101.241 Sprint SPRINT-W (NET-206-159-0-0-1) 206.159.0.0 - 206.159.255.255 Sprint com FON-34665525765801 (NET-206-159-101-0-1) 206.159.101.0 - 206.159.101.255 ping 206.159.101.241 PING 206.159.101.241 (206.159.101.241) from 63.105.122.7 : 56(84) bytes of data. From 63.105.122.1: Destination Host Unreachable From 63.105.122.1: Destination Host Unreachable show ip bgp 206.159.101.241 % Network not in table It was there as recently as Noon EDT : grep 206.159.101.0 bgp.full* bgp.full.Oct_30_00:07:00_EST_2008:* 206.159.101.0 38.101.161.116 62050 0 174 1239 6157 i bgp.full.Oct_30_06:07:00_EST_2008:* 206.159.101.0 38.101.161.116 62050 0 174 1239 6157 i bgp.full.Oct_30_12:07:00_EST_2008:* 206.159.101.0 38.101.161.116 62050 0 174 1239 6157 i Regards Marshall ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again. - Direct Marketing Ass'n position on e- mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Re: Sprint / Cogent
Looks like maybe Sprint and Cogent are experiencing communications difficulties in the DC (and probably other) areas. Theories include a potential depeering. I am seeing issues Cogent - Sprint at Tyco Road, Tysons Corner VA. .. ... .. show ip bgp 206.159.101.241 % Network not in table It was there as recently as Noon EDT : grep 206.159.101.0 bgp.full* bgp.full.Oct_30_00:07:00_EST_2008:* 206.159.101.0 38.101.161.116 62050 0 174 1239 6157 i bgp.full.Oct_30_06:07:00_EST_2008:* 206.159.101.0 38.101.161.116 62050 0 174 1239 6157 i bgp.full.Oct_30_12:07:00_EST_2008:* 206.159.101.0 38.101.161.116 62050 0 174 1239 6157 i All my traffic to Sprint is not being trasported over Cogent backbone here in Central Europe. Regards Michal
Depeering as an IPv6 driver (was: Re: Sprint / Cogent)
I wonder if judicious use of 6to4 and Teredo would allow an IPv6 (single homed) user to access now missing parts of the Internet. Me thinks, yes. Deepak Joe Greco wrote: Looks like maybe Sprint and Cogent are experiencing communications difficulties in the DC (and probably other) areas. Theories include a potential depeering. ... JG
Re: Depeering as an IPv6 driver (was: Re: Sprint / Cogent)
On Oct 30, 2008, at 6:55 PM, Deepak Jain wrote: I wonder if judicious use of 6to4 and Teredo would allow an IPv6 (single homed) user to access now missing parts of the Internet. Me thinks, yes. So would some CGN (Carrier Grade Nat anyone) too. Last I knew Cogent wasn't doing any IPv6.. has that changed? - Jared
Re: Depeering as an IPv6 driver (was: Re: Sprint / Cogent)
On 10/30/08, Jared Mauch [EMAIL PROTECTED] wrote: On Oct 30, 2008, at 6:55 PM, Deepak Jain wrote: I wonder if judicious use of 6to4 and Teredo would allow an IPv6 (single homed) user to access now missing parts of the Internet. Me thinks, yes. So would some CGN (Carrier Grade Nat anyone) too. Last I knew Cogent wasn't doing any IPv6.. has that changed? - Jared Not that I know of. We tried to get IPv6 transit from Cogent several months ago (we already have IPv4 transit), and were told it's not available yet. -brandon -- Brandon Galbraith Voice: 630.400.6992 Email: [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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.
Re: Depeering as an IPv6 driver
Brandon Galbraith wrote: Not that I know of. We tried to get IPv6 transit from Cogent several months ago (we already have IPv4 transit), and were told it's not available yet. What a shame. It's extremely miserable, but Sprint has a 6to4 at least. No clue what they have beyond that. It's been a big motivator for us peering native IPv6 so we can push our customers away from that death trap. Yeah, we can tunnel, but most tunnel peers seem low band. Jack
Re: Sprint / Cogent
http://www.earthtimes.org/articles/show/sprint-nextel-severs-its-internet-connection-to-cogent-communications,603138.shtml Brandon Galbraith wrote: On 10/30/08, Patrick W. Gilmore [EMAIL PROTECTED] wrote: On Oct 30, 2008, at 6:08 PM, Joe Greco wrote: Looks like maybe Sprint and Cogent are experiencing communications difficulties in the DC (and probably other) areas. Theories include a potential depeering. Not a theory. Indeed. It appears, using Sprint's looking glass, that they're completely partitioned from Cogent. YMMV. -brandon -- Paul R Fleming Lead Network Administrator Dimenoc Inc Cell - (407)-267-0227 Office - (407)-756-1126 ext 3001 signature.asc Description: OpenPGP digital signature
Re: Sprint / Cogent
On 10/30/08, Paul Fleming [EMAIL PROTECTED] wrote: http://www.earthtimes.org/articles/show/sprint-nextel-severs-its-internet-connection-to-cogent-communications,603138.shtml The most interesting part of the press release to me is: In the over 1300 on-net locations worldwide where Cogent provides service, Cogent is offering every Sprint-Nextel wireline customer that is unable to connect to Cogent's customers a free 100 megabit per second connection to the Internet for as long as Sprint continues to keep this partitioning of the Internet in place. Unfortunately, there is no way that Cogent can do the same for the wireless customers of Sprint-Nextel. -brandon
Re: Peering - Benefits?
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 [EMAIL PROTECTED] 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.
Re: Peering - Benefits?
On Thu, Oct 30, 2008 at 9:41 PM, Patrick W. Gilmore [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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.
Re: Peering - Benefits?
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
Re: Peering - Benefits?
On Oct 31, 2008, at 1:05 AM, vijay gill wrote: On Thu, Oct 30, 2008 at 9:41 PM, Patrick W. Gilmore [EMAIL PROTECTED] 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
Re: Peering - Benefits?
On Thu, Oct 30, 2008 at 10:13 PM, Patrick W. Gilmore [EMAIL PROTECTED] wrote: On Oct 31, 2008, at 1:05 AM, vijay gill wrote: On Thu, Oct 30, 2008 at 9:41 PM, Patrick W. Gilmore [EMAIL PROTECTED] 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
