- NANOG - lists.nanog.org

Re: UUNET Pulling Peering Agreements & replacing them with charging under non-disclosure?
by Avi Freedman 06 May '97

06 May '97

Since my name was invoked, I'll comment, even though I've been largely trying to stay out of this. But the question, of course, is not that UUNET wouldn't have connectivity to netaxs, but that it might/would have *poorer* connectivity. And the question is whether UUNET customers will notice, overall, a poorer quality of service due to the disconnection. The issue is really: If UUNET has direct peering via the MAEs with the providers or regionals in the DC area (MAE-East) and SF area (MAE-West), where maybe 20-25% of the net traffic in the US flows through (to pick a number), and a few packets start getting dropped or latency goes up to that much of the 'net, perhaps their customers might notice. And then, who suffers more? It's a shame that things might be looked at that way, but my take on it is that the equation is cost vs. cost (as my friend Dave Van Allen would insist that fun-loving ISPs understand and look at the business justifications for things) - UUNET has cost: { backbone bandwidth + engineering time + loss of revenue by enabling other providers to be "peers" at or near the top } for having peers that do not push 1gbit/sec inside their network and has to weight it against vs. the { possible cost of not having as good connectivity to N providers } As for what happens then, who knows? Pissing wars aren't good for anyone, so let's hope that none of them happen... Avi > You do not understand peering with this statement. If you peer with > someone, you give them access to everything on your network route wise, > but not to your other peers. So with that in mind, your statement is not > true. > > What the point is here, and yes, I am a UUnet customer, is one of my > customers requests something from a network peer, netaxs.net for example, > of UUnets, and next week, UUnet decides Avi's a dork (Avi's not a dork) > and didn't pay the rape fee, so UUnet will no longer peer with netaxs.net. > Now I have now way to retrive data from netaxs.net if that was their only > way to get data onto UUnet's network. > > Now I no longer have a compleate internet connection and UUnet has > defaulted on their contract with me as they no longer are carrying the > data I paid them for. > > ============================================================== > Tim Flavin Internet Access for St Louis & Chicago > Internet 1st, Inc Toll Free Sales & Support 800-875-3173 > http://www.i1.net For more information email info(a)i1.net > ==============================================================

3 3

Re: UUNET Pulling Peering Agreements & replacing them with charging under non-disclosure?
by Tony Li 06 May '97

06 May '97

cnordin(a)ever.just.net (Craig Nordin) writes: > Routing Question: > > If backbone providers A, B, and C are fully peering with one another > and little guy X has no peering with A but does with B and C. Will > packets still travel from X(customer) to A(customer) and back again? Yes, via B or C. That is to say that it's sufficient to buy transit once, assuming the connectivity between A, B and C is working. Note that this isn't always the case. ;-( Tony

1 0

Some of the fairest press coverage I've seen
by Michael Dillon 06 May '97

06 May '97

This URL http://www.zdnet.com/intweek/daily/970430a.html has some of the fairest press coverage of Internet operational problems that I have seen to date. Michael Dillon - Internet & ISP Consulting http://www.memra.com - E-mail: michael(a)memra.com The bottom line is track record. Not track tearing. Not track derailing. But pounding the damn dirt around the track with the rest of us worms. -- Randy Bush

2 1

DNS curiosity
by Ehud Gavron 06 May '97

06 May '97

% nslookup set type=ptr 1.1.1.1 Hmmm. BANZAI.SURFVISION.COM. lserver f.root-servers.net repeat query lserver c.root-servers.net repeat query whois 1.0.0.0 Hmmm. E

2 1

Re: IAHC Issues
by Rick H. Wesson 06 May '97

06 May '97

Mathew, Matthew, > Instead of whining and griping about something that is more than likely too > late to change, why don't we focus on helping implement this insane system > in the MOST sane way possible instead of being counter productive. It is > easier to tear an idea down that it is to build one into a reality. There is a move afoot to start an IETF working group that will define how the IAHC's Shared gTLD Repository will work. We have written a charter and drafted a set of requirements for the system. We are currently working on these documents to make the IESG and our (APPs) AD's happy with them. All are welcome to join in the discussion and help define solutions to the problem of "shared gTLDs magement" For more info about 'coredb' see http://www.imc.org/ietf-coredb/ Subscribe to the list by sending a message with the word 'subscribe' (with out the quotes) to ietf-coredb-request(a)imc.org -Rick -- Rick H. Wesson

1 0

Re: We've been hit by the spammers, please have mercy
by Sanjay Dani 06 May '97

06 May '97

>Meanwhile our real public mail server is vulnerable because >it runs Netscape mail (netra runs solaris 2.4 until SunSoft >gets our copy of 2.5.1 application server off back order; Solaris sendmail may be older, the latest one is 8.8.5: ftp://ftp.sendmail.org/ucb/src/sendmail/sendmail.8.8.5.tar Its sendmail.cf is slightly different from the stock Solaris. If you don't have the time to build, you may get a 2.5.1 sendmail binary (note, it's risky to download binaries, no guarantees implied or expressed etc. etc.) under: ftp://ftp.professionals.com/pub/professionals/sendmail-sunos5.4/sendmail.8.… /usr/ucb/sum 37416 388 .../sendmail.8.8.5 CERT advisories on sendmail are under http://www.cert.org. Sanjay.

1 0

RE: UUNET settlement - A call to arms?
by David Whipple 06 May '97

06 May '97

MSN does not have a "peering agreement" with UUNET. We "BGP peer" with them simply to allow us to somewhat load balance with our other carriers. We do pay for transit, like any other UUNET customer. Thanks. David Whipple, Microsoft Internet Engineering. > -----Original Message----- > From: Matthew James Gering [SMTP:mgering@ricochet.net] > Sent: Friday, May 02, 1997 8:44 PM > To: nanog(a)merit.edu > Subject: Re: UUNET settlement - A call to arms? > > MSN does not peer with UUNet, the pay UUNET for transit, and also > contract > out the dialup to UUNet -- which is a pretty penney from what I heard. > > BTW, what happened to Microsoft's 8% stake of UUNet when UUNet got > acquired > by MFS? > > Matt > > > A big problem here is the gag clause. This means that special deals > will > > be cut for the big companies like IBM and MSN and others.

1 0

We've been hit by the spammers, please have mercy
by dhudes＠graphnet.com 06 May '97

06 May '97

Folks, Over the weekend someone decided to use our (Graphnet/globalis.net) mail server for sending spam. We are in the process of dealing with this and some internal network outages all at once. FYI, our mail server is running the very latest Solaris 2.5.1 + patches but the software is Netscape Mail server which replaces Sendmail with its very own. I thought they claimed it could not be used for transit mail but apparently either the claim was false or I misunderstood. Our small staff is strained to capacity working on these issues this monday morning. Please, stop sending mail to postmaster(a)graphnet.com and attacking us You are making the problem worse by flooding us with mail. Please do not blackhole us we have never been a problem before with this and thought we had taken preventative measures. Obviously these measures failed but we are working with Netscape to understand why their sendmail version allowed this to happen. Don't shoot me, I'm one of the good guys.... We want to take action with law enforcement to find and prosecute the spammer for denial of service attacks and theft of services. Pointers to appropriate law enforcement agencies appreciated, also tips on tracking the source down. Ditto applicable NJ and US statutes. I assume not every spam comes from cyberpromo using one's server for transit mail. Dana Hudes Senior Network Engineer Graphnet

2 2

PR Battle Continues...
by rbenn＠clark.net 06 May '97

06 May '97

A few interesting statements in the press today concerning the domain name battle, including PSI, eDNS, & The White House. You can link to them from: http://www.clark.net/pub/rbenn/naming.html Randy Benn

1 0

sorry for the earlier blank message
by Jeff Young 05 May '97

05 May '97

regarding my suggestion (although terse) with regard to set community no-export. my box ran out of space and mh ate the message (delivered a blank). i would let it go, and continue to look stupid, but i've recieved quite a few messages to let me know that my message was a blank, so to say thank you, please stop now, and to look perhaps even more stupid... :-) press d now or forever conceal your boredom:-), to re-cap, someone described the need to use a purchased connection to sprint (or any other provider) as a customer-traffic-only-peering. the right way to do that would be for the seller to engineer a community that accomplished sending routes to their own customer networks, but not advertising those routes to any of their non-transit peers. given that a majority of the networks that connect to large providers are not bgp speakers (are within the provider's own AS) and those that do speak bgp either take a limited set of routes and have alternate connectivity (ie. a transit provider) or take a limited set of routes and generate default from some of those routes, i thought that a simple work-around for the case of a provider (A) who would like to buy bandwidth from another provider (S) rather than burn interconnect bandwidth for traffic to and from that same provider (S) would be to set no-export on the advertised routes to that provider (S). Given that the provider (A) already had global reachability and only wanted to get to the other provider's (S) customers through the bandwidth purchased from that provider (S) set no-export fails for those customers of the provider (S) who are singly-homed to provider (S) and are default-free. ie, if another network (X) takes full routes from the provider (S) and has no other connectivity and no gateway of last resort, provider (A) is not visible to the original network (X). i didn't think of this case, i can't think of why someone would want to be homed to only one provider and be default-free, but i'm sure that there's a reason. the other part of the message was to point out the sh ip bgp nei a.b.c.d adv command which others have already done. Jeff Young young(a)mci.net

1 0