- Test - lists.nanog.org

Draft NANOG agenda
by Susan R. Harris 19 Jan '99

19 Jan '99

Greetings - here's a draft of the agenda for next week's meeting. ------------------------------------- Sunday, Jan. 31 - Afternoon Tutorials ------------------------------------- 1:00-2:50 p.m. BGP 101: BGP Concepts Made Easy (Howard Berkowitz) 3:10-5:00 p.m. BGP 102: A Mid-Sized Network Configuration Case Study (Avi Freedman, Net Access) Monday, Feb. 1 -------------- 9:00 a.m. Welcome, Introductions, Future Meetings (Craig Labovitz, Merit) 9:15 a.m. Routing Scalability in Backbone Networks (Enke Chen, Cisco) 9:45 a.m. Multiprotocol Label Switching: Progress in the IETF from an ISP Perspective Curtis Villamizar, ANS, moderator Paul Doolan, Ennovate Networks Tony Li, Juniper Networks Yakov Rekhter, Cisco 10:45 a.m. BREAK 11:00 a.m. Deploying Inter-Domain Multicast Routing (Dino Farinacci, Cisco) 11:45 a.m. A Modest Proposal for Quenching Smurf Amplifiers (Avi Freedman, Net Access) 12:00 p.m. LUNCH 1:30 p.m. Academic NGI Networking: What's the Difference Between Internet2, Abilene, and the vBNS? Paul Love, Internet2, moderator Guy Almes, Internet2 Jerry Sobieski, Abilene John Jamison, MCI/vBNS 2:30 p.m. ARIN Update (Kim Hubbard, ARIN) 2:45 p.m. InterNIC Update (Mark Kosters, InterNIC) 3:15 p.m. BREAK 3:30 p.m. A Novel Use of Distributed Directory Service (Bill Manning, ISI) 3:45 p.m. Network Failure Analysis (Craig Labovitz, Merit) 4:15 p.m. RED Analysis for Congested Network Core and Customer Egress (Bradley Reynolds, QualNet) Monday Evening BOFs ------------------- 7:30-8:30 p.m. Switch Migration and Renumbering at the Chicago NAP (Andrew Schmidt, AADS) 7:30-9:00 p.m. Cflowd Configuration (Daniel McRobb, CAIDA) 9:00-10:30 p.m. Modem Wholesaling in Today's Marketplace: Vendor Approaches and Solutions (Marie Hattar, Nortel) 9:00-10:30 p.m. Managing Filters and Traffic Shaping in Complex Networks (Pete Kruckenberg, inQuo) Tuesday, Feb. 2 --------------- 9:00 a.m. The Ins and Outs of Layer 4+ Switching (Shirish Sataye, Alteon) 9:45 a.m. Cflowd Update (Daniel McRobb, Cooperative Association for Internet Data Analysis (CAIDA) 10:30 a.m. BREAK 10:45 a.m. Internet Engineering Curriculum (Evi Nemeth, CAIDA) 11:00 a.m. IRcache Web Proxy Bake-Off (Duane Wessels, University of California, San Diego) 11:15 a.m. International Exchange Points: Growth and Trends (Bill Manning, ISI) 11:30 a.m. Setting Up a Local Exchange in Denver: Why Haven't More Providers Joined? (Trent Hein, XOR) 11:45 a.m. Closing Remarks (Craig Labovitz, Merit) ------------------------------------------------------------------------- Susan R. Harris, Ph.D. Merit Network, Inc. Phone: 734.936.2100 srh(a)merit.edu Senior Science Writer Fax: 734.647.3185 -------------------------------------------------------------------------

1 0

RE: MCI/CW Security
by Scott McGrath 19 Jan '99

19 Jan '99

Sorry about the the last message got a little click happy... Or the ticket# field has only 16 bits.... > -----Original Message----- > From: TTSG [SMTP:ttsg@ttsg.com] > Sent: Tuesday, January 19, 1999 3:44 PM > To: nanog(a)merit.edu > Subject: Re: MCI/CW Security > > Hi, > > Nope, not just you. I had a human tell me the same thing, and being > less than happy about it I let him know that web addresses don't have "@" > in it (Ok, they can, but thats another story). > > I was assigned ticket #15. I guess they don't have much security > problems. > > They were good to initially follow it up (However, NEVER received > the > confirmation email I was told I should get) but after that.....Nada. > > Tuc/TTSG > > > > > > > Eh ??? > > > > > > With the lack of voice menu clue, I went to > http://www.security.cw.net > > > and found a form.. assigned ticket number "18".. makes me feel really > > > good, to have a global company assign me a two-digit ticket.. but > hey.. > > > > > > Is it just me ? > > > > > > > > > ====================================================================== > > Derek J. Balling | "Bill Gates is a monocle and a white > > dredd(a)megacity.org | fluffy cat from being a villain in the > > http://www.megacity.org/ | next Bond film." - Dennis Miller > > ====================================================================== > >

1 0

RE: MCI/CW Security
by Scott McGrath 19 Jan '99

19 Jan '99

> -----Original Message----- > From: TTSG [SMTP:ttsg@ttsg.com] > Sent: Tuesday, January 19, 1999 3:44 PM > To: nanog(a)merit.edu > Subject: Re: MCI/CW Security > > Hi, > > Nope, not just you. I had a human tell me the same thing, and being > less than happy about it I let him know that web addresses don't have "@" > in it (Ok, they can, but thats another story). > > I was assigned ticket #15. I guess they don't have much security > problems. > > They were good to initially follow it up (However, NEVER received > the > confirmation email I was told I should get) but after that.....Nada. > > Tuc/TTSG > > > > > > > Eh ??? > > > > > > With the lack of voice menu clue, I went to > http://www.security.cw.net > > > and found a form.. assigned ticket number "18".. makes me feel really > > > good, to have a global company assign me a two-digit ticket.. but > hey.. > > > > > > Is it just me ? > > > > > > > > > ====================================================================== > > Derek J. Balling | "Bill Gates is a monocle and a white > > dredd(a)megacity.org | fluffy cat from being a villain in the > > http://www.megacity.org/ | next Bond film." - Dennis Miller > > ====================================================================== > >

1 0

Re: MCI/CW Security
by TTSG 19 Jan '99

19 Jan '99

Hi, Nope, not just you. I had a human tell me the same thing, and being less than happy about it I let him know that web addresses don't have "@" in it (Ok, they can, but thats another story). I was assigned ticket #15. I guess they don't have much security problems. They were good to initially follow it up (However, NEVER received the confirmation email I was told I should get) but after that.....Nada. Tuc/TTSG > > > > Eh ??? > > > > With the lack of voice menu clue, I went to http://www.security.cw.net > > and found a form.. assigned ticket number "18".. makes me feel really > > good, to have a global company assign me a two-digit ticket.. but hey.. > > > > Is it just me ? > > > > ====================================================================== > Derek J. Balling | "Bill Gates is a monocle and a white > dredd(a)megacity.org | fluffy cat from being a villain in the > http://www.megacity.org/ | next Bond film." - Dennis Miller > ====================================================================== >

1 0

RE: ATM Switch Interoperability Fixed!
by Webb, Tremayne 19 Jan '99

19 Jan '99

It appears that the FORE ASX1000 switches and Ascend Switches do some manipulation of the settings you give them. The Ascend switches allocate [SCR (in cells)] * 1.35 as your CAC (Connection Admission Control) and leaves the PCR untouched. The ASX1000 allocates it as [SCR (in cells)] * 1.75 and leaves the PCR untouched. We recalculated the SCRs to equal out and this solved the problem. ~~~~~~~~~~~~~~~~~~~~~~~~~ Trey Webb Sr. NOC Engineer BA Global Networks, Inc. 703-295-4407 ~~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: Alex Bligh [mailto:amb@gxn.net] Sent: Tuesday, January 19, 1999 12:08 PM To: Steve Murray Cc: Martin, Christian; danny(a)qwest.net; nanog(a)merit.edu Subject: Re: ATM Switch Interoperability Steve, Formula looks great (interesting). However certainly (Cisco) AIP's don't traffic shape sufficiently accurately for (Cisco) BPX's not to cause the occassional discard. I figured Lightstreams might be the same. In our case the relevant supplier changed CDVT and it fixed this. -- Alex Bligh GX Networks (formerly Xara Networks)

1 0

Re: RE: ATM Switch Interoperability
by Steve Murray 19 Jan '99

19 Jan '99

Here is the function for the relationship of Burst Tolerance BT (time) and Maximum Burst Size MBS (a number of cells). Most switches allow you to set the MBS and then they calculate the BT based on this function. Definitions: Ts = 1/SCR, Tr = 1/PCR, ts = BT MBS = | 1 + ((CDVT + ts) / (Ts - Tr)) | where |x| stands for the largest integer less than x. for Tr > 1 and CDVT > Tr -1. This function is based on using a unit of micro-seconds for each variable. The corresponding function is used to calculate the maximum burst size B (a number of cells) on the PCR policing: B = | 1 + ((CDVT) / (Tr - 1)) | For Tr > 1 where |x| stands for the largest integer less than x. CDVT must be greater than Tr - 1. This function is also based on units of micro-seconds. It breaks down if Tr < 1 microsecond. At that point a smaller unit of time would need to be subtracted from Tr instead of 1 microsecond. This only matters with very large PVCs with a PCR of over 1000000 cells per second. These values for MBS and CDVT are usually defaulted for the user and the same default applies no matter what the SCR and PCR values are. Some ATM providers set the CDVT and MBS very low and adjust up if problems like you are observing appear. If the lightstream does traffic shape properly this should not be an issue. If you do have traffic shaping on the lighstream you could set the PCR=SCR. You will lose a small amount of burst but will be able to sustain at SCR. The bursts do not really buy you a large amount of extra traffic anyway (unless CDVT and MBS are set high) they are really just there to allow for variations in accuracy of policing between devices. Steve Murray MCI Worldcom steve.murray(a)wcom.com >>> "Martin, Christian" <CMartin(a)mercury.balink.com> 01/15 9:19 PM >>> >We have it matched to the policing policy of the Network Provider. By >increasing the CDVT, we gain some bucket depth, but we are only MUXing 5 >VCCs over one VP. There shouldn't be too much clumping, espescially >considering the load on the switches(low). One thing is interesting, >though: The far end (customers) are all running over DS3 using HEC >delineation. > >A curiosity: Given the parameters below for the contract, particularly >the MBS and CDVT, does it appear that we are being cheated? From my >understanding of the UNI 3.1 spec, the MBS should be adjustable >according to SCR/PCR, given the fact that CDVT is defined as the same >for both SCR and PCR buckets. > >One obstacle that myself and my colleagues have not been able to >overcome is the use (aside from bucket calculation) of the Burst >Tolerance. It is obviously proportional to the MBS, but again, it >appears as if a contract specifying a PCR/SCR of 100000/50000 cells per >sec, should have a higher MBS than a 10000/5000 cell/sec contract. > >Any insights? > >Chris -

2 1

RE: Incompetance abounds at the InterNIC
by Chris Mauritz 19 Jan '99

19 Jan '99

This isn't a bad idea. Imposing a "pay up front" policy on domains that are not first time registrants or renewals of domains that have paid in the past seems like a pretty good way to deter the hoarding that we're seeing now. If the Internic isn't going to change their policy to squelch the problem, they need to improve the performance of their existing process. The current system is completely substandard and is only encouraging those folks that would see the entire process regulated by the gummint. C Chris Mauritz Director, Systems Administration Rare Medium, Inc. chrism(a)raremedium.com -----Original Message----- From: Rich Sena [mailto:ras@poppa.thick.net] Sent: Tuesday, January 19, 1999 10:37 AM To: John M. Brown Cc: Edward S. Marshall; Daniel Senie; Phil Howard; John Fraizer; nanog(a)merit.edu Subject: Re: Incompetance abounds at the InterNIC My take would be register them as the billing contact and remain as the adminstrative contacts - the NIC should then have a page set up that the custoemr can go with a confirmation number to add their credit card info directly - they could afford them a 3 day window to do so - or the domain would be deleted. They could also tag a domain that has been reregistered a 2nd time and demand payment up front before it is registered this time - that gives the customer 1 bite at convenience - and then hve to put up in order to ever actually get that particular domain. On Tue, 19 Jan 1999, John M. Brown wrote: > My only problem with Pay Up Front is that some customers are going > to be dead beat about paying us. I would want to make sure that > there was some recourse to collecting our money or having the > domain placed on hold until fees are paid. The only way that > I can see doing that now is to register the domain under our name > and then transfer it later once we get paid. Way to much work. <snip> -- I am nothing if not net-Q! - ras(a)poppa.thick.net

1 0

NANOG 15 Registration Reminder
by Pam Ciesla 19 Jan '99

19 Jan '99

NANOG 15 Resgistration ends on Friday, 1/22. Cancellations after 1/22 will be charged $35 and registration will be $285 (space allowing). Information for registering can be found on the NANOG webpage http://www.nanog.org. Any questions please contact me. Thanks Pam Pam Ciesla Merit Network,Inc. 734-936-0172 - phone 4251 Plymouth Road 734-647-3185 Bldg.I, Suite C pam(a)merit.edu Ann Arbor, MI 48107

1 0

quick question about mae-la
by hhui＠arcfour.com 19 Jan '99

19 Jan '99

what fibre carriers are available to one wilshire or 4676 admiralty? any contacts on either the isi or mfs side? (mae-la-request(a)isi.edu seems to get me to a defunct mailing-list, and my wcom reps are clueless, as usual.. "what's mae-la? is that a person?") sorry, this should probably be in the faq :( please reply privately, so as not to clutter the list. thanks much, -h

2 1

Re: source filtering
by Tony Tauber 17 Jan '99

17 Jan '99

On Jan 16, 3:04pm, Jay R. Ashworth wrote: > Subject: Re: source filtering > On Wed, Jan 13, 1999 at 10:37:55PM -0500, Tony Tauber wrote: > > On Jan 13, 3:41pm, Scott McGrath wrote: > > > Subject: RE: source filtering > > > GTE and ATT both filter via access lists on the customers CPE routers IF > > > they provide the routers to the customer > > > > It'd be nice if this information came from one of the entities > > named above. Here's a refinement for our part. > > > > GTE does not impose mandatory source address filtering via > > access-lists on customers' CPE routers. However, we have recently > > implemented Cisco's "ip verify unicast reverse-path". > > I think perhaps we have an acronym collision here. I read Scott's > comment to mean "Customer Premises Equipment", since that was the only > parsing that didn't introduce a conflict. > > However, I read Tony's reply as "Customer Provided Equipment", since > that's my usual parsing of that acronym. > > In this case, it makes quite a difference. Clarification? > > Better: why not, Tony? > My meaning, and the one in common use around GTE Internetworking, is "Customer Premises Equipment" which can be supplied by us or the customer. The phrase "customers' CPE" above, would probably have been a tad clearer as just "CPE", especially since most CPE that we manage are in fact supplied and owned by us. Many customers choose to supply and manage their own CPE which means filtering or lack thereof is up to them. Clear? Tony

1 0