- NANOG - lists.nanog.org

Re: The Attitude (was: the Internet Backbone)
by Paul Ferguson 17 Apr '96

17 Apr '96

At 10:32 PM 4/16/96 EDT, EDS(a)RHQVM21.VNET.IBM.COM wrote: > >Flap dampening works on most routers- just have to be aware of what >the effects are, particularly with multiple BGP Peers. >You have to decide whether to dampen outbound and/ >or inbound, and if short duration events like temporary >recalculations of the IGP are considered a "flap". > Excuse me? Care to qualify this comment? - paul >Ed Segal EDS(a)RHQVM21.VNET.IBM.COM 914 684-3976 > > >

1 0

Re: The Attitude (was: the Internet Backbone)
by Paul Ferguson 17 Apr '96

17 Apr '96

At 04:39 PM 4/16/96 -0400, Avi Freedman wrote: >> Exponential backoff works well, too bad the code base that does >> route flap damping isn't really stable enough for production >> use in large parts of the Internet. > >I think the code base that does route flap damp(en)ing is in use in >large parts of the Internet... > I would have a tendency to agree with you on this datapoint. :-) - paul >> Jeremy Porter, Freeside Communications, Inc. jerry(a)fc.net > >Avi > -- Paul Ferguson || || Consulting Engineering || || Reston, Virginia USA |||| |||| tel: +1.703.716.9538 ..:||||||:..:||||||:.. e-mail: pferguso(a)cisco.com c i s c o S y s t e m s

1 0

Re: Some corrections
by Scott Huddle 16 Apr '96

16 Apr '96

> But then, this is all beside the point! The point was that another more > direct path exists, via Chicago, that would stop swamping your DC > routers, and reduce my recorded congestion. If only these regional > providers would cooperate. Mea culpa, the connection to Chicago is a backup T1, Oarnets other T3 connection to us is in Atlanta. > And I see that you are working on the links, even changing the inverse > names for the same address: [collection of traceroutes deleted] These are the new OC3 trunks... -scott

1 0

Re: Some corrections
by William Allen Simpson 16 Apr '96

16 Apr '96

> From: Scott Huddle <huddle(a)mci.net> > Oarnet is an MCI customer as well. they have a T3 connection to our > network at Washington and another to the Chicago area. I think you might > be confusing traffic to them over their dedicated line at Washington > as going over MAE-East. > Thanks, I checked again, and you are correct, it no longer seems to go via the same paths in the DC area that it did in February or March.... Every month, a different path! But then, this is all beside the point! The point was that another more direct path exists, via Chicago, that would stop swamping your DC routers, and reduce my recorded congestion. If only these regional providers would cooperate. However, this little public exchange has stimulated some local comment, and there may be some cooperation at hand. I am deeply gratified! ---- And I see that you are working on the links, even changing the inverse names for the same address: Recording Wed Feb 28 17:42:29 1996 10: 204.70.1.102 core1-hssi-3.WestOrange.mci.net. (226 ms) (273 ms) (214 ms) 11: 204.70.1.106 core2-hssi-2.Washington.mci.net. (229 ms) (238 ms) (231 ms) 12: 204.70.1.73 core1-aip-4.Washington.mci.net. (240 ms) *** (248 ms) 13: 204.70.2.3 border3-fddi-0.Washington.mci.net. (231 ms) (235 ms) (240 ms) 14: *** 204.70.58.10 ohio-state-u--oarnet.Washington.mci.net. (267 ms) (235 ms) 15: *** 206.21.252.2 oeb-fddi-gwoeb2.columbus.oar.net. (1298 ms) (376 ms) 16: 199.18.105.250 (266 ms) (254 ms) *** 17: *** *** 192.20.239.132 ds2.internic.net. (277 ms) Recording Mon Mar 18 22:25:27 1996 10: 204.70.1.102 core1-hssi-3.WestOrange.mci.net. (226 ms) (273 ms) (214 ms) 11: 204.70.1.106 core2-hssi-2.Washington.mci.net. (243 ms) (379 ms) (240 ms) 12: 204.70.74.52 borderx1-fddi-1.Washington.mci.net. (325 ms) (281 ms) (250 ms) 13: 204.70.74.102 mae-east-plusplus.Washington.mci.net. (251 ms) *** (284 ms) 14: *** *** *** 15: *** *** *** 16: *** *** *** Recording Tue Apr 16 20:29:01 1996 9: 204.70.1.102 core1-hssi-3.WestOrange.mci.net. (214 ms) (201 ms) (201 ms) 10: 204.70.4.129 core1.Washington.mci.net. (307 ms) (367 ms) (214 ms) 11: 204.70.2.3 border3-fddi-0.Washington.mci.net. (206 ms) (205 ms) (208 ms) 12: 204.70.58.10 ohio-state-university.Washington.mci.net. (223 ms) (218 ms) (217 ms) 13: 206.21.252.2 oeb-fddi-gwoeb2.columbus.oar.net. (227 ms) (219 ms) (218 ms) 14: 199.18.105.250 (442 ms) (245 ms) (226 ms) 15: *** *** *** 16: *** *** *** 17: *** *** *** Note that the last 2 times, I still couldn't reach my final destination, ds2.internic.net. Of course, I usually only record the trace when there is an ongoing problem.... WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

Re: The Attitude (was: the Internet Backbone)
by William Allen Simpson 16 Apr '96

16 Apr '96

> From: "Erik E. Fair" (Internet Architect) <fair(a)apple.com> > Perhaps the easy way out is to suggest that educating the ISPs as to > what constitutes good behavior at an exchange (routing system stability > and reliable packet delivery) is the responsibility of the exchange > operators, This is not just the easy way out, I believe that it is the only way out. Then, we don't have the problem of all those multiple peering agreements. Instead, just one with the exchange. Also, this eliminates the problem of each ISP trying to "filter" bogus routes. Instead, the exchange operators will handle that problem. Indeed, I think that this is/was a major impetus for "policy-based" routing in the first place (reading the old RFCs), and a clear reason we need the Routing Arbiter! > and it might even be possible to enforce some interesting > policies in that regard in the route servers (e.g. if you have more > than N routing or BGP peer transitions per time period, the route > server will refuse to peer with you for 48 hours - think of it as the > hold-down or damper from Hell). > Interesting concept! > I certainly think that to the extent that the exchange operators can > measure such things as routing and peer stability, it is in everyone's > interest to see the numbers (except those ISPs who are unstable). Who > knows? A series good reports from exchange operators about an ISP might > lead to offers of private peering arrangements outside of the exchange, > to the benefit of the ISP. Similar to the way that having a good credit > record seems to lead to endless offers of more credit. > I understood that the RA contract provided for these measurements, and agree that they would be a good thing! WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

3 2

Re: Some corrections
by Scott Huddle 16 Apr '96

16 Apr '96

At 9:59 AM 4/16/96, William Allen Simpson wrote: >Both Merit and CICnet are connected to MCI. Correct? My new >understanding is that the problem seems to be that MCI is stuck in the >middle there, and for some reason shunts some (but not all) OSU and >OARnet traffic off through MAE-East, rather than passing it more >directly to OARnet (through CICnet or otherwise). And this is because >of some _source_ based algorithm, since this only happens to Merit >sourced traffic, but not other CICnet traffic, as you are using MCI to >hold together pieces of CICnet? Sounds bizarre to me.... Bill, Oarnet is an MCI customer as well. they have a T3 connection to our network at Washington and another to the Chicago area. I think you might be confusing traffic to them over their dedicated line at Washington as going over MAE-East. Hope this clears things up, -scott (huddle(a)mci.net) MCI Internet Engineering

1 0

Re: Some corrections
by rrv＠uiuc.edu 16 Apr '96

16 Apr '96

At 9:59 AM 4/16/96, William Allen Simpson wrote: >Both Merit and CICnet are connected to MCI. Correct? My new >understanding is that the problem seems to be that MCI is stuck in the >middle there, and for some reason shunts some (but not all) OSU and >OARnet traffic off through MAE-East, rather than passing it more >directly to OARnet (through CICnet or otherwise). And this is because >of some _source_ based algorithm, since this only happens to Merit >sourced traffic, but not other CICnet traffic, as you are using MCI to >hold together pieces of CICnet? Sounds bizarre to me.... > >In any case, it still proves my point -- Merit and CICnet (and MCI) >somehow view each other as competitors and don't cooperate to carry >traffic by the "best" route, thereby clogging other areas of the >Internet (MAE-East) at others' unknowing expense. Bill, you are way off base.

1 0

Re: The Attitude (was: the Internet Backbone)
by William Allen Simpson 16 Apr '96

16 Apr '96

> From: Jeremy Porter <jerry(a)fc.net> > Bill, here is why you will never be taken seriously be > any ISP/NSP. If networks can't find ways to cooperaate without > prodecting there own interests, we all might as well give up > now. > I'll try to remember not to take myself seriously.... This is a most unusual argument: that we should cooperate without protecting our own interests; and if we cannot, we should give up. Are you sure that you know what you are writing? > THE ONLY WAY TO BUILD A SCALABLE INTERNET IS FOR PROVIDERS > TO BE MOTIVATED BY SELF INTEREST AND ECONOMIC FACTORS. > This is contrary to your above assertion. However, this does not match the historic record. A scalable Internet doesn't even require the concept of "providers". Nor does it require self interest. There are certainly other models that could be (and have been) followed. > This is exaclty an issue of customer education, If customers > wanted good connectity they CAN find it. > Really? Where? And who does the education? Using what data (as the providers themselves have refused to release it)? May I suggest that this form of argument was advanced for rather a lot of other fields, such as food, drugs, comparing doctors and lawyers and their fees, and purchasing of automobiles and refrigerators. As I remember, Consumers Union (I'm a lifetime member) was investigated at one time as a "communist conspiracy". This does not follow the subject of this thread, which was in regard to (lack of) cooperation with competitors. I don't see how customer education will affect the physical interconnections of carriers, except as perhaps encouraging consumers to sue their providers for fraud.... > Hm.. maybe Apple should have thought a little more > about their little T-1 link to a single provider when they > had about 3 T-1s worth of data to send. I offer to sell > more connectivity to Apple, but they WEREN'T interested. I question your objectivity. Sounds like you have a personal self-interest issue here. By my measurements, there was no problem with the Apple T1(s). The problem I documented was that Sprint didn't have enough bandwidth out of Texas (specifically to Chicago in my tests, but reportedly to other places as well) to ensure full T1 delivery for Apple while also supplying service to others in Texas. That is, Sprint was underprovisioned. Also, their links flapped a lot. > They didn't care that there application/distribution model was > broken, and breaking the net, they didn't want to fork > out the extra bucks, or deal with the internal politics > to put the release out on the West coast where they > had a much higher bandwidth connection. > I disagree, as Apple DID care very much! In fact, they eventually did put it out on other sites, including their west coast connection. How would it have helped if they had a T3 in Texas, when Sprint couldn't even handled another T1's worth of traffic to the same site? How would it have helped the net if they had been multihomed? You provide a separate link to Chicago, and load balancing between you and other providers? > I haven't seen many reports of Sprint problems since > Sprint put its policies in places and they had time work. Only recently has Sprint been cooperating with the RA enough to actually get some Sprint flapping statistics. I cannot help that you personally have not seen them.... Why not look at them yourself? > MCI on the other hand has been bleeding about 30% packets out of > San Francisco, on its OWN INTERAL network for several MONTHS. Too true. I did not mean to pick on Sprint exclusively, except where Sean seemed to make a claim that somehow the Sprint network was somehow operating better then others, and that it was due to his wonderful sagacity in refusing to carry others traffic. I have not (yet) heard the same non-cooperative attitude from MCI. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

2 1

Re: Some corrections
by William Allen Simpson 16 Apr '96

16 Apr '96

> From: Dorian Kim <dorian(a)cic.net> > On Mon, 15 Apr 1996, William Allen Simpson wrote: > > I am admittedly confused here. CICnet provides connectivity from UMich > > to OSU, and the other Big Ten schools. CICnet is physically connected > > to UMich and MichNet, and also to OSU and OARnet. > > This used to be the case. This is right now not the case. This maybe the case > again in the future. Confused yet? Welcome to the world of academic > networking. :) >... > Depends on what you mean. AS266 traffic goes through MCI to get to AS1225. >... > I'm still curious where you got this false impression of the situation. > Apparently, I was missing some pieces (that had not been described in your earlier messages), and remembering "old" information (as above). Both Merit and CICnet are connected to MCI. Correct? My new understanding is that the problem seems to be that MCI is stuck in the middle there, and for some reason shunts some (but not all) OSU and OARnet traffic off through MAE-East, rather than passing it more directly to OARnet (through CICnet or otherwise). And this is because of some _source_ based algorithm, since this only happens to Merit sourced traffic, but not other CICnet traffic, as you are using MCI to hold together pieces of CICnet? Sounds bizarre to me.... In any case, it still proves my point -- Merit and CICnet (and MCI) somehow view each other as competitors and don't cooperate to carry traffic by the "best" route, thereby clogging other areas of the Internet (MAE-East) at others' unknowing expense. Indeed, this sounds even closer to the UK situation, where they are too cheap to install a local European link, and instead steal from the other vendors' links to Europe through the MAE-East commons. WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

1 0

35th IETF Report Available
by lscanlan＠cix.org 16 Apr '96

16 Apr '96

An extensive summary report of the 35th IETF, held in March in Los Angeles, California, is now available at the CIX web site, http://www.cix.org/Meetings/ietf-35.html Highlights of the meeting topics covered by Mark McFadden, CIXtra's technical reporter, include: Explorations of Alternative Routing and Topology IRAD Portable Site Prefixes Exchanges Stratum-based Aggregation Globally Redundant Routing Information DNS-based Logical Routing Conclusion Internet Architecture Board Character Sets in the Internet IAB, IRTF and IETF Issues Hearing on Returning a Standard to Draft Standard Status Applications and Transport Joint Session "Netscape Hack" HTTPng Caching T/TCP Transaction TCP HTTP 1.0 Short-term Solutions HTTP Version 1.1 HTTP and Multicasting Other Work Ipng Working Group IP Security IPv6 Mobility Routing Aspects of the IPv4 to IPv6 Transition Agents, Mobile Code and Intelligent Agents CIDRD Lou Scanlan Member Information and Services Email: helpdesk(a)cix.org Voice: 703 8 CIX CIX

1 0