November 1995 - Test - lists.nanog.org

one typo correction...
by Steve Heimlich 06 Nov '95

06 Nov '95

Change "aggregate" to "advisory" as below. Steve ------- > Date: Mon, 06 Nov 1995 18:43:22 -0500 > From: Steve Heimlich <heimlich(a)kingbee.ans.net> > To: nanog(a)merit.edu > Subject: AS690 policy configuration changes > > > All, > > Starting with Friday morning's config run, AS690 will pick up any > route listed in various routing registries, including both those > routes with advisories and those routes without advisories. > > ANS customers will not be affected by this change. > > Routes without advisories will be examined for origin AS and will > inherit the most popular policy currently used for that AS. For > example, if a route for 147.225/16 (origin AS1660) were listed > without an advisory, we would configure ourselves to listen for > 147.225/16 in the same way that we listen to most other AS1660 > routes (only from AS 1324 in this case). > > If a route is registered in an AS for which we don't have existing > policy, it will not be routed. In the example above, if 147.225/16 > were registered without an aggregate, and it were the only route ^^^^^^^^^ This should be "advisory." [...]

1 0

AS690 policy configuration changes
by Steve Heimlich 06 Nov '95

06 Nov '95

All, Starting with Friday morning's config run, AS690 will pick up any route listed in various routing registries, including both those routes with advisories and those routes without advisories. ANS customers will not be affected by this change. Routes without advisories will be examined for origin AS and will inherit the most popular policy currently used for that AS. For example, if a route for 147.225/16 (origin AS1660) were listed without an advisory, we would configure ourselves to listen for 147.225/16 in the same way that we listen to most other AS1660 routes (only from AS 1324 in this case). If a route is registered in an AS for which we don't have existing policy, it will not be routed. In the example above, if 147.225/16 were registered without an aggregate, and it were the only route registered with origin 1660, then we will not route it. We have a tool which flags such new ASes, and policy toward them will be created regularly. The rate of growth in number of ASes is not high, particularly relative to the rate of growth in number of routes. For now, we will continue to build our policy dynamically from the advisory attributes. Assuming that this hybrid deployment goes well, we intend to freeze our policy and convert to a system which ignores advisories altogether. With this system, the mechanics of shifting policy will be quite easy (essentially involving only ANS). I expect to announce that freeze and shift in the next week or so. At that point, those folks who want to strip AS690 advisories from any database may do so without a problem; as mentioned above, any advisories registered after that time will be ignored. Steve

1 0

Re: links on the blink (fwd)
by Vadim Antonov 06 Nov '95

06 Nov '95

Paul Vixie wrote: >(As long as I'm singing the GIGAswitch's praises, I'd like to add that DEC >is planning a GIGAswitch-to-GIGAswitch interconnect product but it will only >run at a few hundred megabits, not the full b/w of the crossbar; and further, >they now sell an ATM version of the GIGAswitch in case you don't want FDDI >but you need an ATM with working congestion control.) It also supports full-duplex FDDI, which is about as fast as ATM/AAL5 over OC-3 and has no ATM problems (i.e. things like multicasting work as they are supposed to). Now if only YFRV produced devices which could talk full-duplex FDDI and native IP over SONET... --vadim

1 0

More on IPSPA.ORG
by Tim Bass 06 Nov '95

06 Nov '95

Okay, so I am a little nuts. I've sent a domain template to the NIC for IPSPA.ORG.... It just seemed like the right thing to do :-) 1) Next week, I'll register IPSPA as a non-profit corp in some nice state; 2) Maybe we will get lucky and have some members; 3) We will build low cost NAPs for IPSPA.ORG members; 4) We will aggressively solicit corporate and government funding for projects; 5) We will drink beer and eat pizza at our meetings; 6) We will throw together an IPSPA.ORG home page; 7) We can watch all the big IP players laugh as we grow and take a lot of abuse as a new organization; 8) We might even draft an IPSPA post NSF AUP for fun and address topics like child pornography, spam, and other impossible topics; 9) We will hire Washington lawyers to advocate our position on every front in the beltway and use PGP as a rule; 10) Maybe we will form a non-profit common carrier while we are at it and substantially reduce all IPSPA.ORG members transit costs; 11) We will have our meetings only in the best climates depending on the season; 12) We will think of ways as a 'new frontier' network based organization to generate income ( and beg money from members ); 14) We will create a board of directors that are not enjoy well defined conflicts of interests (maybe); 15) We will apply to the FCC for our on set of frequencies to develop lost cost wireless access at T1 speeds and above. Between laughing and while we are waiting on the new domain and I get motivated and fix Majordomo..... IPSPA-request(a)ipspa.silkroad.com soon to be: IPSPA-request(a)IPSPA.ORG Why not? Other ideas and organizations have happened. Stranger things have happened..... and with enough support... who knows? Tim -- +--------------------------------------------------------------------------+ | Tim Bass | #include<campfire.h> | | Principal Network Systems Engineer | for(beer=100;beer>1;beer++){ | | The Silk Road Group, Ltd. | take_one_down(); | | | pass_it_around(); | | http://www.silkroad.com/ | } | | | back_to_work(); /*never reached */ | +--------------------------------------------------------------------------+

8 17

Re: More on IPSPA.ORG
by Eric Kozowski 06 Nov '95

06 Nov '95

>> 3) We will build low cost NAPs for IPSPA.ORG members; > >You laugh ... however, RTD is a few short weeks away from having NAPs up >and running in Tucson and Phoenix. > >It's primarily intended for local providers, so that we can at least >control quality standards in the region ourselves. If larger peers want >to show up, nobodies going to kick them out of bed though...we've got a bed >big enough for everybody. hehe. A NW peering point is currently about 3-4 weeks away. Initially it will be done via fully meshed frame relay, until traffic dictates otherwise. This peering point will be _solely_ for keeping local traffic local and not for providing transit. If anyone is interested, there is a mailing list, nw-internet(a)structured.net (subscription requests to majordomo(a)structured.net) setup for discussing this. Eric -- Eric Kozowski Structured Network Systems, Inc. kozowski(a)structured.net Better, Cheaper, Faster -- pick any two. (503)656-3530 Voice "Providing High Quality, Reliable Internet Service" (800)881-0962 Voice 56k to DS1

1 0

Re: links on the blink (fwd)
by salo＠msc.edu 06 Nov '95

06 Nov '95

> To: nanog(a)merit.edu > Subject: Re: links on the blink (fwd) > Date: Mon, 06 Nov 1995 00:21:09 -0800 > From: Paul A Vixie <paul(a)vix.com> > [...] > [praise of the DEC GIGAswitch deleted...] > ... and further, > they now sell an ATM version of the GIGAswitch in case you don't want FDDI > but you need an ATM with working congestion control.) Contact your DEC sales representative to verify these details, but: o The GIGAswitch FDDI switch has an OC-3c ATM interface. However, the last I knew it could only be used to communicate with another GIGAswitches. In other words, it could connect with another GIGAswitch, perhaps through an ATM network, but it could not connect to, for example, an ATM host. When I looked at this, it supported only PVCs, although SVC support was planned. o DEC productized the AN2 ATM switch, and gave it a confusing name something like GIGAswitch ATM. The AN2/GIGAswitch ATM has basically nothing in common with the GIGAswitch FDDI switch. The AN2 implements a credit-based congestion control mechanism. The ATM Forum adopted, after long debate, a rate-based congestion control mechanism. In my opinion: o The GIGAswitch FDDI switch is a great box. o The GIGAswitch ATM switch is one of a number of switches which ought to be examined when selecting an ATM switch. -tjs

1 0

Re: links on the blink (fwd)
by Jonathan Heiliger 06 Nov '95

06 Nov '95

On Nov 4, 10:16pm, William Allen Simpson wrote: > My solution is to take the contracts away from MFS and Ameritech > effective immediately, and grant them to someone who knows what they are > doing. >-- End of excerpt from William Allen Simpson I have to echo Mike's comments... MFS offers the MAE interconnect service to customers who choose to purchase it. (As far as I know) As you infered and Mike said; portions of MAE-East are definately nearing saturation. Specifically the shared FDDI portion which; according to my diagram contains the MCI vBNS connection, ANS (they also have a Gigaswitch port, however I believe their shared FDDI connection is preferred), and BBN (keep in mind, it might not be correct :). All of these folks are sucking up a good bit of bandwidth all their own -- combine them and you have the equivalent of a fire hydrant pumping water through garden hoses. Now then, I'm sure the appropriate engineering staff at each respective organization is weighing whether to change their MAE connection to a Gigaswitch port, connect directly to certain other NSPs, or even to build their own exchange point. My only closing points would be that, as far as I can determine, both Ameritech and MFS seem to be handling problems reasonably well. One of the reasons I joined the MFS team was because of their attitude to quickly increase service capacity and/or to respond to customer's requests. Rather than doing things too quickly (wasting cash) or doing it too slowly and having a bunch of un-happy customers. speaking for myself... -jh-

4 4

Re: More on IPSPA.ORG
by owen＠DeLong.SJ.CA.US 05 Nov '95

05 Nov '95

> Uh, you have been pre-dated by about 3 years by the > > Commercial Internet Exchange > > lots of network operators and access providers already belong. > > If what you propose hasn't been done in that already-existing forum, > maybe there's a reason that would foretell the expected success > of another parallel organization? > > -mo > I don't know... CIX has some fundamental flaws. CIX was primarily built, as near as I can tell, to carry out the personal agendas of a select few. I don't know whether or not IPSPA has a chance of avoiding this problem. However, CIX has definitely suffered as a result of some of it's policies and attitudes. Owen

1 0

Re: links on the blink (fwd)
by Scott Bradner 05 Nov '95

05 Nov '95

> > Well, I don't think I will need to be reminded not to buy Internet service > > from your organization. > > Why not? We don't run the Internet, we just connect people to it. As has been said about New Yorker cartoons, if you don't get it, no amount of explanation will help. Scott

3 2

Re: links on the blink (fwd)
by Scott Bradner 05 Nov '95

05 Nov '95

> 10% packet loss is quite within the normal range of parameters for a > packet switching network such as the Internet. Well, I don't think I will need to be reminded not to buy Internet service from your organization. Here is a bit of context. At home I am a beta site for the PSI Internet service via cable TV. I generally use a computer at Harvard University to read my mail. Although the Harvard network is about 1.5 miles away from my house the sparse distribution of connections between Internet service providers and the current routing policies mean that packets from my house to Harvard take 20 hops and go through San Francisco and packets from Harvard to my house, (also 20 hops) go through Washington DC. Here are the results of some reliability tests I just ran. from my house to San Francisco via PSI Net: 209 packets transmitted, 209 packets received, 0% packet loss round-trip min/avg/max = 99.996/268.978/983.334 ms from Harvard to Washington DC via BBN Planet and MCI 204 packets transmitted, 204 packets received, 0% packet loss round-trip (ms) min/avg/max = 16/46/249 from my house to Harvard via PSI, MAE-west, MCI, BBN Planet and back via BBN Planet, MCI, MAE-east and PSI. 505 packets transmitted, 497 packets received, 1% packet loss round-trip min/avg/max = 116.702/192.69/3000 ms (Note this is being tested at a time when Harvard's service provider (BBN planet) is busily working on one of the links in its backbone because they do not think the quality is high enough.) I consider it a problem when the loss exceeds 1% through this long path - as do the people who run the networks that my traffic passes through. The normal loss through this path is less than 1% and, much of the time it is 0. > But nothing is broken. There is no inter-ISP level. It is so much easier to just say it is the other guy's problem. Hans-Werner suggests that most phone companies do not take this attitude, lucky for some of us, not all Internet "service" providers do. Scott (just in case you might think I'm off on some other world, there are other paths I could have used which would have shown far higher loss, those paths would have gone through service providers who apparently feel the way that the person quoted here does or who are unable to make the investment in their infrastructure warranted by the level of traffic their customers would like to exchange.)

3 3