October 1996 - Test - lists.nanog.org

Re: AGIS/DIGEX
by Chris A. Icide 29 Oct '96

29 Oct '96

At 07:00 PM 10/29/96 -0500, Robert Laughlin wrote: >So now we all watch to see who blinks first, or is universal >connectivity no longer a goal? I suppose each side is blaming the >other. What a way to run Internet. > Well, I wouldn't be suprised if more of this continues to occur. IMHO, peering is currently a huge financial bean for the counters, along with being a strategic bean. Significant amounts of money ride on peering. Let's say that AGIS is the only hold out for DIGEX to go defaultless. If this is the case, and the traffic from DIGEX to AGIS is significant, DIGEX could be forced to spend a not in- significant amount of money to resolve said issue. Technically, if they had to, the best choice would be to purchase said circuit from AGIS (I wonder if they would do this?). Either way, they end up purchasing a circuit from thier competitor. But this is peering 101, and doesn't belong on this list.... Anyway, my point is that peering has become a financial decision, and sooner or later people are going to start throwing them attourney types at these things. And many companies will have a good case, when the issue is between two companies of equivalent "net worth". This is begging for the folks in DC to get thier paws in on this. Those of us who have spent previous time in regulated industries probably know that this is NOT in our best interests, no matter which side of the issue you are on. Chris A. Icide Nap.Net, L.L.C.

1 0

Net Realty
by Paul Ferguson 29 Oct '96

29 Oct '96

Not like this is, like, late-breaking news or anything, but I thought some of you might find this article entertaining. http://www.news.com/News/Item/0,4,4896,00.html [snip] Net realty for sale October 29, 1996, 12:45 p.m. PT Domain names are a hot commodity in the "cyberspace real estate" market, and a Beverly Hills company today said it's hoping to strike it rich by helping Netizens buy and sell popular names for a ten percent commission. [snip] - paul

1 0

@Home (was Re: AGIS/DIGEX)
by Sean Donelan 29 Oct '96

29 Oct '96

Will someone please fix com-priv(a)psi.com so this traffic can be redirected to a more appropriate list... @Home told me they require peers to be at three exchange points, except @Home was only at three exchange points (mae-east, west, and sprint) at the time. I told Cathy thanks, and to let me know when they were at some more exchange points we had in common to meet their own list of peering requirements (cix or chicago whenever Ameritech's sales force gets around to bringing up our circuit). >This is all very interesting information. It seems at-home recently did >the same thing with us, as they stopped all transit and were not on CIX, >basically forcing us to peer with them. Is this the route to get peering >with the big players that will now evolve? Forced peering due to >unreachability? -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

1 0

Re: AGIS/DIGEX
by Paul Ferguson 29 Oct '96

29 Oct '96

At 07:22 PM 10/29/96 -0500, Dorian R. Kim wrote: > >This is all going back to Geoff Huston's animals running across each other in >the middle of the night thing. > I actually *liked* that analogy, btw. ;-) - paul

1 0

Re: Peering is a lot of work.
by Kent W. England 29 Oct '96

29 Oct '96

At 03:10 PM 29-10-96 -0500, Justin W. Newton wrote: > >One can point default at someone whether or not they are peering with the >person. I am somewhat confused by the thought that people believe that >they need to be peering with someone to have that person point default at >them. I could (I don't, but I could), point default at /anyone/ on the >same switch fabric as me, whether they are peering with me or not. Why do >people continue to tie these 2 issues together? > The two issues are intertwined because whether or not default is tied to peering depends on which sort of media your public exchange uses. A FDDI exchange point will allow anyone to point default at anyone else without any explicit BGP peering or FDDI configuration, but an ATM NAP requires a permanent virtual circuit to be established between two peers before traffic can flow and this requires the consent of both peers. Therefore, on an ATM NAP, you are not subject to default-abuse by non-peers. --Kent

1 0

Re: Peering is a lot of work.
by salo＠msc.edu 29 Oct '96

29 Oct '96

> Date: Tue, 29 Oct 1996 15:10:26 -0500 > To: "Kent W. England" <kwe(a)6SigmaNets.com>, > Robert Laughlin <robert(a)portal.dx.net> > From: "Justin W. Newton" <justin(a)erols.com> > Subject: Re: Peering is a lot of work. > [...] > One can point default at someone whether or not they are peering with the > person. I am somewhat confused by the thought that people believe that > they need to be peering with someone to have that person point default at > them. I could (I don't, but I could), point default at /anyone/ on the > same switch fabric as me, whether they are peering with me or not. Why do > people continue to tie these 2 issues together? > [...] Unless, of course, you are using ATM for your NAP or interconnect medium. -tjs

1 0

Re: Peering is a lot of work.
by doug＠pbi.net 29 Oct '96

29 Oct '96

On Oct 29, 15:10, Justin W. Newton wrote: > > One can point default at someone whether or not they are peering with the > person. I am somewhat confused by the thought that people believe that > they need to be peering with someone to have that person point default at > them. I could (I don't, but I could), point default at /anyone/ on the > same switch fabric as me, whether they are peering with me or not. Why do > people continue to tie these 2 issues together? > At the PacBell Nap for instance, you *couldn't* just point default at anyone on the same switch fabric -- because you need to set up a peering (mapping) within the switching fabric first, before you do any route peering. Until this happens there would be no unwanted traffic. -d

2 1

Re: You are right [was Re: Ungodly packet loss rates]
by Jeremy Hinton 29 Oct '96

29 Oct '96

I hate to whip a dead horse, but letting stuff like this pass as accepted is probably not the best thing... > <jhall(a)rex.isdn.net> writes: > > well if you're going to compare ciscos and bay networks routers, > consider that Bay networks supports Rip, OSPF, BGP, and EGP. They do > *NOT* support communities in their production software, Actually, its in 11.0, which is now production software, and i *think* it might even have made it into 10.x. No confederations AFAIK. > and they have *NO* > intentions of *EVER* supporting confederations. In adition, to handle > subnets, where you want the thing to summarise a subnet into a classful > route, the Bay's solution is to drop the route entirely. I you mean the trait of using classfull mask defaults for route aggregation, yes that is/was an issue. I think 11.0 has a switch to turn that off now though (if not production, one of the workspaces). Its not a major issue really, as this can easily be accomplished with policy filters, which is how we do it. I would say this is the preferable way to do it, as it isolates bogus IGP information and makes troubleshooting much easier. > They also don't > seem to understand how to aggregate routes. Their solution there is also > to drop the route. They do not appear to have the option to announce the > aggregate with the routes. They also do not appear to have the option of > aggregating since the option they provide does not work. Their SNMP > agent only works on a few platforms, and in order to adequately solve a > routing problem, you need to have a *GOOD* understanding of the MIB. This is false. I used to believe this too, and am quite familiar with the MIBs as a result. But then there is TI scripting, and it made life much simpler (at least, it made wfIpBaseRtEntry.7.* much easier to type). The ip commands in 10.x also make this easier. Of course, this is all if you're a die-hard CLI fan. > last time I enabled syslog on the box, the router reloaded several times > within a 5 hour period, causing instability in our small network, small > meaning under 200 routes. Can't speak for this, as i do local logging, not syslog. However, we currently have several Bay boxes with full internet routes and multiple peers, and the only problem i've had recently is from a Cisco peer feeding me bad announcements. > I have fought with these things for 3 years > now and haven't seen much improvements. They have been promising NTP > support for quite some time now, since their routers don't have a > battery-powered clock. Maybe the reason they can switch packets faster NTP client is in 11.0, though not server. > and more reliably than ciscos is because they are unable to be placed in > a situation to really test their skills. The items I have shown here > make it VERRY difficult to allow one of these things to perform with > full routing because you cannot determine what it will do. We have actually seen quite a bit of improvement (and i'll be the first to admit, there was a lot of room for it). However, i'm not sure i agree with your statement about 'full routing'. We are running BGP, RIP, and OSPF all here, in various nodes, without serious problems. True, you do need to have a good understanding of accept/announce policies, but i find the performance/capability more than acceptable. - jeremy // Jeremy Hinton Visionary Systems, Inc. // jgh(a)visi.net http://www.visi.net // Network Engineer Newport News, VA // A little nonsense now and then is relished by the wisest men

1 0

Re: Peering is a lot of work.
by Warren Williams 29 Oct '96

29 Oct '96

> >On Oct 29, 15:10, Justin W. Newton wrote: >> >> One can point default at someone whether or not they are peering with the >> person. I am somewhat confused by the thought that people believe that >> they need to be peering with someone to have that person point default at >> them. I could (I don't, but I could), point default at /anyone/ on the >> same switch fabric as me, whether they are peering with me or not. Why do >> people continue to tie these 2 issues together? >> > >At the PacBell Nap for instance, you *couldn't* just point default at anyone on >the same switch fabric -- because you need to set up a peering (mapping) within >the switching fabric first, before you do any route peering. Until this happens >there would be no unwanted traffic. This came up at NANOG, and, yes, while with ATM the PVCs bring the automatic ability of shielding one from unwanted traffic from a "non-peer", a provider **could** point default at one of his peers. There is nothing that can be done at the L2 level. We could, again as mentioned at NANOG, bring down the PVC upon the request of only one of the peers, ending the default situation, but this is reactive, and requires that the default scenario still be detected... Kind regards, Warren

1 0

Re: Peering is a lot of work.
by Justin W. Newton 29 Oct '96

29 Oct '96

At 10:25 AM 10/29/96 -0800, Kent W. England wrote: > But that >still begs the question of adequate defenses against default-pointing and >other bad effects and the business plan which still calls for all of this >to go away. One can point default at someone whether or not they are peering with the person. I am somewhat confused by the thought that people believe that they need to be peering with someone to have that person point default at them. I could (I don't, but I could), point default at /anyone/ on the same switch fabric as me, whether they are peering with me or not. Why do people continue to tie these 2 issues together? > >I now take my large ISP hat off and return to the other side of the table. >I find that many of these same problems affect me if I am a small or new >ISP joining up to a public exchange like the NAPs or MAEs. Now I get 10 >peering requests per week and I run down the list of issues and before I >know it, I'm figuratively back on the other side of the table wondering >how clueless the other party is. > >The public exchanges are useful for a variety of things and they are and >will remain important, but the pressure for private peering points is >considerable as I outlined. Take your high bandwidth traffic to/from your >true peers off to private interconnects and avoid the hassle of the public >bazaar for that part of the bandwidth. The traffic level justifies high >bandwidth pipes for private peerings. > >My suggestion to newcomers and small ISPs is to help advance your cause by >latching onto the route servers and RA contractors as a way to help >yourselves >and your backbone peers. You need a process which can demonstrate that you >are >addressing the issues I outlined above. If that process were to be accepted by >all, then perhaps it would be easier to convince the backbones not to slow >the >peering process, but fix it and maintain it, while continuing private >interconnects as warranted. > >Flame away, but try to stay on point. (Please don't respond and say that the >true figure is 50 peerings per week, even though it may be more accurate.) > >--Kent >Speaking as a PacBell NAP consultant. > > > > Justin Newton Network Architect Erol's Internet Services

3 2