- Test - lists.nanog.org

Re: Hey, anyone who wanna help improve the net stability?
by matthew＠scruz.net 05 Sep '96

05 Sep '96

Original message <Pine.SUN.3.94.960905145324.10907T-100000(a)unix1.netaxs.com> From: Gordon Cook <cook(a)netaxs.com> Date: Sep 5, 15:04 Subject: Re: Hey, anyone who wanna help improve the net stability? ... > > Of the class cs from the swamp how many are now being routed at the > defaultless core? HOW MANY ADDITIONAL CLASS Cs FROM THE SWAMP ARE THERE > FOR WHICH THE OWNERS COULD DEMAND ROUTING? ... Exactly as many class C's as are not yet being routed, minus those which have been voluntarily returned. I believe the return statistics have been made available to nanog before, so perhaps the keeper of them could do this calculation. -matthew kaufman matthew(a)scruz.net

1 0

Re: :)
by John Curran 05 Sep '96

05 Sep '96

At 15:41 9/4/96, Enke Chen wrote: >The direct interconnection between MCI and Sprint is in >the Chicago area rather than in Denver. The connection >speed is OC12 rather than DS3 :-) Hmm... Do the routers at both ends actually think it's OC12? /John

4 3

Re: Agenda for next NANOG
by Brett D. Watson 05 Sep '96

05 Sep '96

i think this is somewhat related busy naps and overloaded interconnects and i'm wondering if anyone else has noticed this kind of thing. i've noticed in debugging on my border router at mae west (the only place i actually looked at this) there is a lot of broadcast traffic that shouldn't even be propogated at a nap, such as: Sep 5 09:07:02.424: UDP: rcvd src=205.137.63.52(513), dst=255.255.255.255(513), length=68^M Sep 5 09:07:02.424: UDP: rcvd src=205.137.63.52(513), dst=255.255.255.255(513), length=68^M this is a unix box i'm guessing trying to get information via whod on the fddi ring at mae west. i've logged a large number of these broadcasts this evening, all within milliseconds of each other. seems to me we (collectively) don't want/need to see this type of traffic floating around when we're trying to push real customer traffic through the interconnects. or how about broadcasting bootp/tftp requests across the ring? i've logged an equally large number of these tonight: Sep 5 09:06:12.735: UDP: rcvd src=0.0.0.0(68), dst=255.255.255.255(67 ), length= 308^M Sep 5 09:06:12.735: BOOTP: opcode 1 from host 0.0.0.0 on Fddi10/0, 64508 secs, and even better: Sep 5 09:20:16.714: UDP: rcvd src=163.179.51.7(65044),dst=255.255.255 .255(69), length=29 is someone trying to pull a config (any config) via tftp from whomever happens to have one? this kind of traffic just seems very wasteful and unneeded at the naps. i can't see that this is even useful to the folks doing it. more traffic clogging up the pipes. -brett

1 0

:)
by Christian Nielsen 05 Sep '96

05 Sep '96

I guess sometimes they don't like to tell us what kind of link they have. 4 core1-fddi-1.Denver.mci.net (204.70.3.113) 208 ms 29 ms 19 ms 5 somerouter.sprintlink.net (206.157.77.90) 84 ms 90 ms * 6 somerouter.sprintlink.net (206.157.77.90) 86 ms 88 ms 88 ms 7 * sl-chi-6-F0/0.sprintlink.net (144.228.50.6) 168 ms 92 ms Christian

5 4

Re: :)
by Scott Huddle 04 Sep '96

04 Sep '96

Yah, but once you use Cook, Metcalfe, Bass, Fleming, Metzger, Denninger, and Dillon, how do you name the rest? :) -scott > From owner-nanog(a)merit.edu Wed Sep 4 16:46 EDT 1996 > From: Sean Doran <smd(a)icp.net> > To: cnielsen(a)vii.com, roy(a)mci.net > Subject: Re: :) > Cc: nanog(a)merit.edu > Date: Wed, 4 Sep 1996 16:39:06 +0100 > Sender: owner-nanog(a)merit.edu > Content-Type> : > text> > Content-Length: 774 > > | We'd be happy to change this mapping to some other hostname (or CNAME > | the inverse address), if the Sprint folks would prefer something > | different :-) > > Well, I wanted to name our private peerings after the > seven deadly sins, but maybe "somerouter.sprintlink.net" > is a good choice until the names are settled on this side. > > That'll happen when the tactical build-out we began a week > and a half ago is completed in a few days. > > Meanwhile, 206.157.77.90 is sl-chi-15-H1/0-T3.sprintlink.net (anger) > 206.157.77.34 is sl-dc-1-H5/0-T3.sprintlink.net (sloth) > and 206.157.77.66 is sl-stk-1-H9/0-T3.sprintlink.net (pride) > > which are subject to move, and the mapping for the > remaining RRs are not nearly as firm... > > Of course, I like Enke's suggestion too. :-) > > Sean. >

2 1

Re: "Building the Internet backbone"
by schnell＠gsd.sprint.com 04 Sep '96

04 Sep '96

Interesting sales pitch by PacBell. However, the article is littered with technical inaccuracies and claims not entirely true. For instance, Sprint's NAP, which was operational in 3Q94 had virtual connections to every Sprint POP in the U.S. by way of its nationwide ATM service. In addition, which ISPs are lined up to take advantage of PacBell's 622 Mbps ports by year's end? Which routers will they use? ss At 12:43 9.4.96, Stephen Balbach wrote: >"Building the Internet backbone" > >Take a virtual tour of a busy Network Access Point > >by George lawton > >SunWorld Online. > >http://www.sun.com/sunworldonline/swol-09-1996/swol-09-nap.html > >Abstract > > The Internet, of course, consists of many networks strung together. > The Internet's skeleton is made up of high-capacity trunk lines > maintained by telephone companies at sites called "NAPs." This > article outlines the role of NAPs, and profiles Pacific Bell's NAP in > particular. (2,700 words) > > > >--- >Stephen Balbach "Driving the Internet To Work" >VP, ClarkNet due to the high volume of mail I receive please quote >info(a)clark.net the full original message in your reply. ******************************************************************************** Phone: 1.816.854.2113 Fax: 1.816.854.2201 Sprint Pager: 1.888.366.7890, PIN 398.6644 Text Page via Internet: 3986644(a)pagenet.net **************************************************************************** ****

1 0

Agenda for next NANOG
by Susan R. Harris 04 Sep '96

04 Sep '96

Greetings - Here's what we've lined up so far for the Oct. 24-25 NANOG agenda: - vBNS Update - Future router requirements - Multihoming pros and cons - Economics of Internet resource allocation Are there other topics you'd like to hear about? ------------------------------------------------------------------------ Susan R. Harris, Ph.D. Merit Network, Inc. srh(a)merit.edu Phone: (313) 936-2100 Fax: (313) 747-3185 ------------------------------------------------------------------------

7 10

RE: MFS WorldCom/WilTel/LDDS
by Vadim Antonov 04 Sep '96

04 Sep '96

Peter Ford wrote: >My understanding is that RSVP is targeted to solve the problem of offering >services such as audio/video conferencing, audio/video streaming such as >radio/television, and telephony services on the Internet and private >networks that use IP. Resource reservation is nothing more than a prioritization scheme. If there's no sufficient resources to share, doling it differently does not change the fact that resources are not available. All you get by doing resource reservation is to trade packet loss to denial of service. If you think about it, a properly designed voice protocol would sustain 30% packet loss w/o much trouble (say, if you split sample bit stream into nibbles and send bit 0 in a high-priority packet, and bits 1-3 in regular-priority packets); whereas a voice network which is not available 30% of time is very close to useless. >A "problem to start with" is offering these services in the current >Internet does not yet work. Knowing for sure how Internet backbones are provisioned i can say that the solution is in entirely different plane. In fact, if you allocate resources to Internet within the same overcommitment margins as are commonly found in POTS you'll get _better_ quality of service. Without prioritization, that's it. --vadim

1 0

Re: Access to the Internic Blocked
by Sean Doran 04 Sep '96

04 Sep '96

Curtis Villamizar <curtis(a)ans.net> writes: > There are routers that handle {LS}SRR at near full speed. Stuffing it > on the broken path in is a bug. Fast-path/broken-path > is just a bug. I'm not sure I agree, particularly in the case where "broken-path" involves delegating work to another processor. I will agree with you that the fast switching scheme in current IOS is gross, however it was expedient, and is the reason there are so many DS3 networks operational today. Remember that prior to 10.2-viktor it was much worse... The fact that one fast-path/slow-path scheme is broken in several subtle ways does not really convince me that it's a bad idea in general. In particular, when we're dealing with the sorts of time budgets needed to support multiple OC48s per card, while _I_ would love to have a single path and might be willing to live with reduced port-density (clever secondary-circuit wiring, for example) to avoid running too close to per-packet time-budgets, other people might convincingly argue that if one can determine in advance that drops will happen if a particular datagram is fully processed, and the combination of determining that and delegating the work to another processor falls within the time budget under bad-case to worst-case conditions, it's a good idea to have multi-path forwarding. So, yes, simplicity is good and easy to diagnose. Unfortunately, when the diagnosis is a simple "you haven't got enough processing power to handle your traffic pattern using a single path", forwarding-path simplicity is one of the things that needs evaluation. Of course, I am also from the school of thought that someone blasting a huge amount of worst-case traffic on one interface should never affect normal traffic across that and especially not other interfaces. That school doesn't like the thought of not being able to handle a full OC-12's worth of offered traffic on an interface because someone is jamming a large fraction of that bandwidth worth of Christmas-tree packets at someone's router. Discovering that routers X handle Y at "near full speed" always worries me. Consequently, I worry alot. :-) Sean.

2 1

"Building the Internet backbone"
by Stephen Balbach 04 Sep '96

04 Sep '96

"Building the Internet backbone" Take a virtual tour of a busy Network Access Point by George lawton SunWorld Online. http://www.sun.com/sunworldonline/swol-09-1996/swol-09-nap.html Abstract The Internet, of course, consists of many networks strung together. The Internet's skeleton is made up of high-capacity trunk lines maintained by telephone companies at sites called "NAPs." This article outlines the role of NAPs, and profiles Pacific Bell's NAP in particular. (2,700 words) --- Stephen Balbach "Driving the Internet To Work" VP, ClarkNet due to the high volume of mail I receive please quote info(a)clark.net the full original message in your reply.

1 0