[4888] in North American Network Operators' Group
Re: Peering versus Transit
daemon@ATHENA.MIT.EDU (Alan Hannan)
Mon Sep 30 23:11:42 1996
To: SEAN@SDG.DRA.COM (Sean Donelan)
Date: Mon, 30 Sep 1996 22:07:01 -2900 (CDT)
Cc: nanog@merit.edu
In-Reply-To: <960930213648.20263@SDG.DRA.COM> from "Sean Donelan" at Sep 30, 96 09:36:48 pm
From: alan@mindvision.com (Alan Hannan)
Reply-To: alan@mindvision.com (Alan Hannan)
Sean,
It almost makes one think the evil telcos are plotting a new
service/product that would be damaged by legacy contracts, eh?
-alan
internet engineer for the enquirer?
>
> >These days peering agreements are business deals.
>
> They have always been business deals. I'm just amazed as some of the
> lengths some providers go to justify what should be a plain-old
> business decision. If you don't intend to peer with another provider,
> just say so. The only providers I tend to get really peeved at are
> the ones that keep changing their stories.
>
> AGIS told me in January '96 that their peering agreement was being
> revised by their lawyers and they would send it as soon as it was
> ready. Since I hadn't heard from AGIS in a while, I sent another
> note to AGIS and was told they now require DS3 connections to four
> exchange points. No idea what happened to that peering agreement
> from January.
>
> MCI told me in February '96 that their peering agreement as
> on hold pending review by their lawyers and they would let me know
> when it was ready. The last response I've received from MCI is the
> person in charge of peering had changed. No word from the new guy.
> And MCI took their peering policies off their web page. No idea
> what happened to MCI's policies in the mean time.
>
> Since March of 1995 (yes '95) I've gone through three product managers
> for Sprintlink who have told me their peering agreement is on the way,
> under legal review, on hold, or being revised. DRA met Sprint's peering
> 'requirements' a couple of times now. But by the time I hear back from
> their product manager du jure, they've changed their requirements again.
>
> I'm puzzled why these providers seem to have new peers show up at the
> same time they are telling me new peerings are on 'hold.' Should I
> start taking this personally? If you don't intend to peer with other
> providers, why not say so? Why go through the trouble of making
> peering questionaires and listing peering requirements, when you are
> just going to come up with a new excuse if you don't want to peer
> with the other provider.
>
> >They happen to
> >be business deals that have $0 attached to them for all sorts
> >of reasons Sean D et al explained far more eloquently than I could,
> >but they are still business agreements. Just like any other contract,
> >be in breach at your peril.
>
> Breach of contract is a civil matter, not criminal. If you have a
> peering agreement that says thou shalt not next-hop third-party routes,
> and they do, you get to terminate the agreement and/or sue the other
> provider, not arrest them.
>
> People seem to be very quick to call things they don't like illegal.
> Not all misrouted packets are the result of illegal activities, most
> of them are just misrouted packets. MCI didn't plan to send me packets
> across mae-east, they just happened to believe some bad routing information.
>
> If you are going to start arresting people simply because packets are
> misrouted, big providers misroute a lot more packets than little providers
> simply due to size. This is a dangerous game to start playing because
> it can easily blow up in your face.
>
> >Which leaves the case where you send traffic to say ISP X
> >*without* any form of peering agreement with ISP X. Contracts
> >with the IXP should prevent this from happening. If you
> >try this, I hope they filter your MAC address.
>
> Some IXPs do this, but the operators aren't always able to keep up with
> the changing arrangements of the various providers and end up blackholing
> a bunch of traffic every so often for varying lengths of time. The routing
> protocols have problems dealing with networks which don't have the 'shared-
> fate' property.
>
> Most other IXP contracts are silent about relationships between ISPs.
> --
> Sean Donelan, Data Research Associates, Inc, St. Louis, MO
> Affiliation given for identification not representation
>
--
Alan Hannan
Not Employed Networking, Ltd.
email: alan@mindvision.com.
phone: 402/488-0238
