On 3/28/06 8:58 AM, "Patrick W. Gilmore" <[EMAIL PROTECTED]> wrote:
> > Why would someone believe what the networks tell them over what other > _users'_ experiences are? You say it is a good basis for comparison, > but I have trouble believing that - unless you mean: "A good basis to > see which network's marketing department is better." > > If I were doing things like leased lines or dark fiber - something > more objective and not quite such a moving target - an RFP might make > sense. For things like transit, you need real people who know how > networks really react to real problems, how networks really pass real > packets, how clueful real network NOC techs are, etc., etc. None of > these are covered in RFPs (despite what the networks might tell you). > > So thanx for the suggestion, but I think I'll stick with _customer_ > feedback rather than what the networks want to tell me themselves. > > Also, many networks will not respond to an RFP for the levels of > traffic people here are considering. Those who don't believe that an RFP can work for them don't know how to write an appropriate RFP. Clue level is important, but frankly, less important than it used to be, now that the business of building large IP networks is a more or less known quantity. How to assess support? There are plenty of metrics like time to resolve complaints, and percentage of issues resolved in a single call (very important). Escalation paths are also an important element of an RFP. Getting hard numbers on stuff like packet loss across peering and upstream transit links is important and an RFP is a good way to get these numbers with more assurance than an email from your sales rep. Of course, there are plenty of silly RFP questions like "who do you peer with and where" - with no mention of capacities or utilization! -- Daniel Golding
