- NANOG - lists.nanog.org

Phoenix Topics
by Susan Harris 13 Jan '03

13 Jan '03

Here are the talks we've scheduled so far for the Phoenix NANOG, Feb. 9-11: Sunday Tutorials - A Methodology for Troubleshooting Interdomain IP Multicast Level: Intermediate/Advanced Bill Nickless & Caren Litvanyi, Argonne Nat'l Lab - BGP Techniques for Service Providers Level: Introductory Philip Smith, Cisco - BGP Troubleshooting with Juniper Examples Level: Intermediate/Advanced Joseph M. Soricelli, Juniper - IPv6 Deployment Concepts Level: Intermediate Tony Hain, Cisco General Session (Monday - Tuesday) - Experiences with Large-scale Network Consolidation (Or, How I Spent My Summer Vacation) Dave Israel & William Charnock, Allegiance Telecom - BST: BGP Scalable Transport Van Jacobson, Cengiz Alaettinoglu, & Kedar Poduri, Packet Design - Internet Exchange Operator Panel Mike Hughes, LINX, moderator - Peering Evolution Daniel Golding, AOL Time Warner - SIP Operation in the Public Internet: What Makes Running It a Challenge and What it Takes to Deal With It Jiri Kuthan, iptel.org - High Density Wireless Deployment Joel Jaeggli, University of Oregon - Large Scale Wireless Networks, UT's Case Philippe Hanset, University of Tennessee - CIDR Police - Please Pull Over and Show Us Your BGP Announcements Barry Greene, Cisco; Hank Nussbacher, Riverhead Networks - IPv4 Address Allocation and BGP Routing Table Evolution Cathy Wittbrodt, Packet Design - BGP4 Anycast for Root Name Service -- Threat or Menace? Suzanne Woolf, ISC; Mark Schleifer, Cogent - Operational Testing of DNS Resources - IPv6/DNS Symbiosis Bill Manning, ISI - The BGP TTL Security Hack (BTSH) Dave Meyer, Sprint - Lack of Priority Queuing on RPs Considered Harmful Vijay Gill, AOL Time Warner - Update on the 802.17 RPR Standard Andrew Brown, Cisco Monday Afternoon Research Forum - Achieving Near-Optimal Traffic Engineering Solutions for Current OSPF/IS-IS Networks Ashwin Sridharan & Roch Guerin, University of Pennsylvania Christophe Diot, Sprint Monday Evening BOFs - Peering BOF VI Bill Norton, Equinix, moderator - ISP Security BOF II Barry Raveendran Greene, Cisco Merike Kaeo, merike.com, moderators Abstracts for most talks are on the web: http://www.nanog.org/mtg-0302/topics.html Looking forward to seeing you, and please reserve your hotel room before Saturday, Jan. 18, when the NANOG rate expires: http://www.nanog.org/mtg-0302/hotel.html

1 0

Test, drop it...
by Alexei Roudnev 13 Jan '03

13 Jan '03

Alexei Roudnev =============

1 0

Iraq net shutdown temporarily
by Sean Donelan 12 Jan '03

12 Jan '03

http://www.sfgate.com/cgi-bin/article.cgi?f=/c/a/2003/01/12/MN125083.DTL Baghdad -- Apparently in response to a blanket e-mail campaign by the U.S. military urging dissent and defections, the Iraqi government shut down -- at least temporarily -- all Internet access and the country's two e-mail servers. Although no official explanation was given, e-mail service stopped midafternoon on Friday. Some service was resumed Saturday morning.

4 3

hotmail problem
by Oscar Valdez 12 Jan '03

12 Jan '03

some problem with www.hotmail.com right now??? the page doesnt open. -- Oscar

4 3

Re: US-Asia Peering
by brandon＠rd.bbc.co.uk 11 Jan '03

11 Jan '03

> what the > restrictive-peering network owners are looking for is "are you a peer in > real life?" which translates loosely to "are you going to be able to sell > to the same customers i do whether i peer with you or not?" That's always good for a laugh "we encourage you to build yourself up to compete with us" "you must match our business model and infrastructure" though I hope that doesn't include having to engage in fraud too brandon

1 0

Re: US-Asia Peering
by Paul Vixie 11 Jan '03

11 Jan '03

> > packetexchange already does this between any number of IXP's. the > > only technical issue is whether to trunk the connection between > > packetexchange and the IXP (at PAIX we don't -- each such extended > > vlan gets its own port without vlan tagging and counts as a normal > > customer connection.) the nice economic angle in all this is that > > it's an IXP-independent service, so if someone at LINX-Docklands > > wanted to talk to someone at PAIX-NY, it'd work. > > yes but to clarify as most exchanges enforce a single mac address per > port and you dont want to bridge the two ixps you will have at least > one L3 hop between the IXPs, which protects you against the nasties of > large L2 topologies and L2 meltdowns which all goes to why PAIX doesn't trunk its connections to packetexchange (or telseon or yipes or etc.) (or SIX or NYIIX or etc.) > > 2. laughability. noone who peers remotely in this way will qualify ... > > thats odd, surely the main purpose of this requirement is to ensure > that the peering is as cost neutral as possible, eg someone peering > with Sprint at a single site exchanging global routes (own, customer) > will clearly save the ISP money and cost sprint who now have to ship > traffic to and from that site - a good case for not peering or peering > only local routes. whether the mechanism by which the interconnect is > enabled is long reach ethernet or sdh or whatever doesnt seem > important to the peering policy as i said previously: peering isn't about cost or technology. what the restrictive-peering network owners are looking for is "are you a peer in real life?" which translates loosely to "are you going to be able to sell to the same customers i do whether i peer with you or not?" one of the litmus tests is "backbone strength", where an L1 backbone is considered to be in a completely different strength class from an L2-L2.5-L3 backbone.

1 0

Re: US-Asia Peering
by woody＠pch.net 11 Jan '03

11 Jan '03

Y'all havin fun with them straw men, Bill? ----Original Message---- From: "William B. Norton" <wbn+woody%nemo.corp.equinix.com(a)paixhost.pch.net> Subject: Re: US-Asia Peering At 09:33 AM 1/10/2003 -0800, Bill Woodcock wrote: > On Fri, 10 Jan 2003, Stephen J. Wilcox wrote: > > In response to Randy and Bill(s), this seems to come down to a > trade off of > > commercial vs technical. A lot of us agree this is technically not > the best way > > and produces instabilities with the potential to take out major > chunks of > > internet but it is cheap and this means people will adopt this way > of doing it, > > unfortunately as this has now happened it means those opposed to > the idea will > > have to also consider this as an option if they are to compete. > >I don't think it's fair to characterize it as a trend... I mean, ten >years ago, we were all (generalizing here) stupid enough to try these >tricks. Fortunately, smarter people have come along since, and learned >from our mistakes. There are also _vastly_ more people involved in the >industry now than then, so it comes as no surprise that there are still >some newbies trying this, despite all the lessons of the past. The good >news is that although they're a quantitatively growing group, they're a >shrinking _fraction_ of the whole. So that's evidence of some small >progress in the state of knowledge. Fight the law of conservation of >clue! > > -Bill Bill - the argument seems like Proof by Rigorous Assertion: I know it is a bad idea. I really really believe it is a bad idea. My friends say it's a bad idea. Not one that I know says it is a good idea. Therefore, and I can't emphasize this enough, in conclusion, it is a bad idea. If what you are saying is true, I'd really like to hear just a couple of insurmountable technical problems with WAN L2.5 infrastructure interconnecting IX switches. For the sake of argument and to clarify the discussion (Paul) let's make a few assumptions: 1) We are talking about an operations model where IX switches are operated by a single company. 2) The IX switches are interconnected by MPLS by a transport provider offering that service. 3) An ISP on one switch creates a VLAN for peering with ISPs on any of the other switches. This ISP VLAN is only for peering with the ISP that created this VLAN. Since he is paying for the VLAN traffic he has this right. 4) The cost of transporting the traffic between the switches is bourne by a transport provider who in turn charges the ISP that created the VLAN in question. I can articulate a half dozen reasons why this is a good idea. Please share with us why this is a such a bad idea. If it has been tried before, it would be helpful to point to specific the case and why it failed, the technical failure scenario. I'd like to hear why/how it was worse by the distance between switches. Bill

1 0

iij contact
by Scott Granados 10 Jan '03

10 Jan '03

Wonder if there is an iij america contact around if so could you contact me off list. Thanks Scott

1 0

RE: frame relay to atm conversion tool?
by Brennan_Murphy＠NAI.com 10 Jan '03

10 Jan '03

I now have a prototype spreadsheet. Email me offline if you are interested in getting a copy...maybe helping in making it more accurate. Thanks, BM -----Original Message----- From: Peter E. Fry [mailto:pfry@swbell.net] Sent: Thursday, January 09, 2003 10:46 PM To: nanog(a)merit.edu Subject: RE: frame relay to atm conversion tool? On 9 Jan 2003 at 17:45, Swaminathan, Sekar wrote: > Instead of Frame Relay frames, you have to look at the > payload which is usually IP packets. Here is the formula > that I would use: [...] Specifying an "average packet size" is rough: I've observed that on an "average Internet connection" around 35% of packets are 64 bytes, 35% 1500 bytes, and the remainder scattered about. The average is guaranteed to be a poor match for at least 70% of your traffic. Not that it matters. Most carriers configure FRATM VCCs as "1536kbps frame relay = 4500cps", treating fractions accordingly. The last thing you want to do is exceed this cell rate (around 1710kbps at a 1500-byte packet size), as on a policed link you'll lose nonconforming cells. (Actually, a 1536kb frame relay seems to be closer to a 1705kb ATM VCC. Eh, the IWF has to buffer some anyway.) If you increase your cell rates you potentially oversubscribe your frame link (and the IWF may disallow it in any case). So if you're tempted to exceed this ratio be very certain of your link characteristics. Add to that: when a sustained rate is defined (VBR service category) the ATM peak rate probably doesn't mean what you would expect, so I recommend sustained = peak. (ABR is the best match for data, but isn't often used.) As to the original question, I wouldn't recommend translating a burstable frame to ATM unless you can order an ABR VCC or get UPC and/or frame discard disabled on your link (don't bet on it). It's not likely you can match parameters, so without flow control you're essentially looking at reduced performance or packet loss under load. Whatever you do get, I recommend you ask your carrier for a spec. You have plenty of variables and relatively robust protocols, meaning you could take a shot, miss, and only find out for certain that you had when you'd really rather not. Get it reasonably right, though, and it'll do right by you. Huh. Now that I look at it, I need to rethink my own figures yet again (I haven't even implemented the last rethink) as I appear to have tended toward the conservative in some areas. Grrr. Take it easy. Peter E. Fry

1 0

RE: Puerto Rico Peering Point, or existence thereof.
by Ray Burkholder 10 Jan '03

10 Jan '03

http://www.napoftheamericas.net/membersrepresentativecustomerlist.cfm http://www.napoftheamericas.net/memberscarriers.cfm -----Original Message----- From: Randy Bush [mailto:randy@psg.com] Sent: January 10, 2003 15:59 To: David Barak Cc: Bill Woodcock; Ray Burkholder; nanog(a)merit.edu Subject: Re: Puerto Rico Peering Point, or existence thereof. > However, NOTA doesn't have either AT&T or WorldCom... so, did any of the much-ballyhooed florida (misnomered) naps actually manage to attract the significant (== big tier-1) isps? randy

4 3