- Test - lists.nanog.org

Mae-East Reboot?
by Deepak Jain 10 Oct '97

10 Oct '97

Was the Mae-East reboot scheduled or unscheduled? -Deepak.

6 5

Draft NANOG Agenda
by Susan R. Harris 10 Oct '97

10 Oct '97

Here's the current schedule - see you in Phoenix! ----------------------------------------------------------------------------- SUNDAY, Oct. 26 7:00-8:30 pm Tutorial: "Raise your Routing IQ - Design and Debugging Techniques for Intermediate Users" Avi Freedman, Net Access 8:30-10 pm TOOL DEMOS (see http://www.nanog.org/mtg-9710/tools.html) -------------------------------------------------------------------------- MONDAY, Oct. 27 Time Topic/Presenter(s) ---- ------------------ 9:00 a.m. Welcome, Introductions, Future Meetings Bill Norton, Merit 9:30 a.m. Fighting Spam: Lessons, Legality, and Solutions Paul Vixie, Vixie Enterprises 10:15 a.m. Fighting Spam: Panel Discussion John Levine, abuse.net Justin Newton, Priori Networks Paul Vixie, moderator 10:45 a.m. BREAK 11:00 a.m. ISP/Telco Forum: Issues and Answers Mark Knopper, Internet Engineering Group, moderator 12:00 p.m. LUNCH 1:30 p.m. Freely Available Statistics Reporting Agents: A Practical Review Stan Barber, Academ Consulting Services 2:00 p.m. Plans for the Internet Routing Registry Transition to Routing Policy Specification Language Cengiz Alaettinoglu, ISI 2:30 p.m. Internet Routing Registry Cleanup Efforts Curtis Villamizar, ANS 3:00 p.m. Introduction to BIND-8 Paul Vixie, Vixie Enterprises 3:30 p.m. BREAK 3:45 p.m. Routing Analysis and Tools from the Internet Performance Measurement and Analysis Project (IPMA) Rob Malan, University of Michigan 4:15 p.m. Update from the Internet Protocol Performance Metrics (IPPM) Working Group Vern Paxson, Lawrence Berkely Lab 4:45 - An Architecture for Global Internet Statistics Collection 5:15 p.m. Scott Huddle, MCI ---------------------------------------------------------- 7:30-9 p.m. TOOL DEMOS VENDOR DEMOS Interprovider Operations BOF Jake Khuon, Merit Abha Ahuja, Merit Craig Huegen, Quadrunner Other BOFs TBA -------------------------------------------------------------------------- TUESDAY, Oct. 28 9:00 a.m. Update from IOPS.ORG TBA 9:30 a.m. ARIN Update Kim Hubbard, InterNIC 10:00 a.m. InterNIC Update David Holtzman, InterNIC 10:30 a.m. BREAK 10:45 a.m. Router Scalability Issues: Overview and Panel Curtis Villamizar, ANS, moderator Dave O'Leary, Cisco TBA, Ascend 12:00 p.m. LUNCH 1:30 p.m. Gateway Congestion Control: A Warning, a Plea, and an Offer of Help Van Jacobsen, Lawrence Berkely Lab 2:00 p.m. Dynamic Selection of Geographically Distributed Servers Alec Peterson, Erols Avi Freedman, Net Access 3:00 p.m. Closing Remarks Bill Norton, Merit -------------------------------------------------------------------------- Susan R. Harris, Ph.D. Merit Network, Inc. Phone: 313.936.2100 srh(a)merit.edu Senior Science Writer Fax: 313.647.3185

1 0

Re: Emerging Technologies
by Tony Li 10 Oct '97

10 Oct '97

> For emerging technologies (i.e. PNNI, MPOA, IPv6, RSVP) which IGP would > you use OSPF or EIGRP in a cisco enviroment on a global network ? Part of your sentence makes no sense to me. As to which IGP is appropriate, there needs to be a coherent routing architecture before you select an IGP. One size does not fit all. Tony

1 0

Re: ATM (was Re: too many routes)
by Tony Li 10 Oct '97

10 Oct '97

dhudes(a)graphnet.com (Mr. Dana Hudes) writes: > Note that this trick of downloading full routes to linecards > didn't originate with Cisco... I don't think that anyone was arguing that. If they were, they're Just Plain Wrong. Tony

1 0

Problems with UUnet and Sprint peering
by Anthony Pardini 10 Oct '97

10 Oct '97

Is anyone else having problems sending taffic between UUnet and Sprint ? This has been occuring for a least a week and so far I've just gotten the Its Sprint / Its UUnet run around. The problem is that there is too much traffic 40+Mbit/s each way between these two routers. 144.232.4.13 (sprint) and 137.39.166.121 (uunet) Any suggestions on getting this resolved? or who handles the peering agreements between these two companies? --------------------------------------------------------------- Tracing route to www.uu.net [199.170.0.30] over a maximum of 30 hops: 1 <10 ms <10 ms <10 ms cisco7505-3.cmpu.net [204.181.108.1] 2 10 ms 10 ms 10 ms 144.228.137.13 3 10 ms 10 ms 10 ms sl-fw-19-F6/0/0.sprintlink.net [144.228.30 4 40 ms 50 ms 50 ms 144.232.8.70 5 40 ms 40 ms 40 ms 144.232.4.21 6 40 ms 50 ms 50 ms 144.232.4.14 7 1712 ms 1713 ms * Hssi4-0.BR1.SFO1.ALTER.NET [137.39.166.121 8 1532 ms 1542 ms * Fddi0-0.CR2.SFO1.Alter.Net [137.39.41.38] 9 1442 ms * 1322 ms 133.Hssi-2.GW2.FFX1.Alter.Net [137.39.71.7 10 1352 ms 1402 ms 1372 ms UUNET7-GW.UU.NET [137.39.12.162] 11 1412 ms 1352 ms 1352 ms charlotte01.va.pubnix.com [199.170.0.30]

3 2

Emerging Technologies
by Patrick O'Keefe 09 Oct '97

09 Oct '97

For emerging technologies (i.e. PNNI, MPOA, IPv6, RSVP) which IGP would you use OSPF or EIGRP in a cisco enviroment on a global network ?

1 0

ATM (was Re: too many routes)
by Sean M. Doran 09 Oct '97

09 Oct '97

Richard Irving <rirving(a)onecall.net> writes: > Ok. I will bite, although I hate to open my mouth, as my shoe always > seems to bee-line for it.. ;} Hehe. > I don't think so.... how about the ability to mix > voice, MPEG, and IP on the same pipe ? Um, I do this now with IP. Admittedly with parallel circuits (virtual or hard) I could send such traffic down different pipes to partition congestion effects, however to do this right I'd really want to use MPLS/tag switching anyway. When I make the decision to use MPLS/tag switching I also have to consider that there is decent queuing available in modern IP routers (that will effectively become hybrid IP routers and MPLS/tag switches) and that I can neatly partition the traffic without using actual or virtual circuits. > Or, how about that with ABR my delay across the ATM > fabric is reduced when I have more bandwidth open. (POTS > is low on utilization, during this "theoretical moment > in time") A couple milliseconds and a few extra Mbs can > count ;) You want bounded delay on some traffic profiles that approach having hard real time requirements. (Anything that has actual hard real time requirements has no business being on a statistically multiplexed network, no matter what the multiplexing fabric is). This can be implemented in routers now, with or without MPLS/tag switching, although having the latter likely makes configuration and maintenance easier. ABR is another attempt to do statistical multiplexing over a substrate that is not well geared to anything other than TDM. It interacts poorly with any protocol that is developed to run over a statistically-multiplexed network (e.g. TCP) and there are little demons with respect to the way RMs are handled that can lead to nasty cases where you really don't get the bandwidth you ought to. The problem again is that mixing TCP and other statmux-smart protocols with ABR introduces two parallel control loops that have no means of communication other than the interaction of varying traffic load, varying delay, and lost data. This often leads to the correct design of additive increase/multiplicative decrease traffic rate response to available bandwidth leading to a stair-step or vacillation as more bandwidth becomes available to each control loop, and a rather serious backing off at the higher level when available bandwidth is decreased even fairly gently. Delay across any fabric of any decent size is largely determined by the speed of light. Therefore, unless ABR is deliberately inducing queueing delays, there is no way your delay can be decreased when you send lots of traffic unless the ATM people have found a way to accelerate photons given enough pressure in the queues. > Oh, 2 things come to mind, my variability throughout an ATM cloud is > greatly reduced versus a routing cloud, a cell requires WAY less time to > cross a switches backplane, versus a packet through a router. And > seriuosly less time to determine where to send it... Um you need to be going very slowly and have huge packets for the passage through a backplane to have any meaning compared to the centisecon propagation delays observed on long distance paths. I know of no modern router that delays packets for anything approaching a handful of microseconds on fast interfaces except in the presence of outbound queues being congested, where if you're running TCP you really want to induce delay rather anyway, so that the transmitter will slow down. > Ok. So, maybe Cisco's Flow Switching approaches VBR having a bad hair > day. (and tuned for SERIOUS tolerance, CDVT=10,000), but certainly not > traditional routing. The analogy between VBR and flow switching confuses me. Could you explain this a bit? Actually, maybe you could explain the rest of the message too, because I think we have a disconnect in terms of vocabulary. :( Sean.

25 37

(Fwd) Re: Request for your advice
by narlar＠agcs.com 09 Oct '97

09 Oct '97

HI, I don't know if this is someone's email address or a mail list. Either way, please excuse me for taking the liberty to mail this to you. BUt I have an urgent need to know general pricing information for T1 and T3 pipes from business to ISP and from ISP to the backbone. I would appreciate if you'd point me in the right direction. Thank you. Ramaiah --- Forwarded mail from Avi Freedman <freedman(a)netaxs.com> From: Avi Freedman <freedman(a)netaxs.com> Subject: Re: Request for your advice To: narlar(a)agcs.com Date: Thu, 9 Oct 1997 16:09:37 -0400 (EDT) Worldcomm IXC Qwest Sprint MCI Are all possibilities. Why not post to nanog(a)merit.edu with the question? > On Oct 9, 3:28pm, Avi Freedman wrote: > > Subject: Re: Request for your advice > > > > > > > Are you looking for raw clear-channel pipes or IP transit pipes? > > > > Avi > > I'm interested in raw clear-channel pipes. Thank you for your response, > Avi. > > Ramaiah > > > -- > AGCS Business Development, 2500 W. Utopia Rd., Phoenix AZ 85027 > Ph: (602) 581-4324 Fax: (602) 581-4495 "Expand The Power Of Your Network" > ---End of forwarded mail from Avi Freedman <freedman(a)netaxs.com> -- AGCS Business Development, 2500 W. Utopia Rd., Phoenix AZ 85027 Ph: (602) 581-4324 Fax: (602) 581-4495 "Expand The Power Of Your Network"

1 0

Re: UUNet Routing SNAFU
by Mark Milhollan 09 Oct '97

09 Oct '97

>> What about the cable providers that have chunks of 24/8? > >62/8, 63/8 and 64/8 are being assigned now. > >So you just relax the filters according to what's being assigned. AT&T has been allocating customers from 12/8.

5 5

Re: UUNet Routing SNAFU
by Danny McPherson 09 Oct '97

09 Oct '97

> You may want to check out our configuration generation tool RtConfig in > http://www.isi.edu/ra/RAToolSet. RtConfig does a good job of generating those > 46K+ lines automatically from IRR. Generating ACLs from the IRRs and deploying the configs is no problem. Booting my router afterwards is.. -danny

1 0