Full Abstract

PAIX.Net Update

PAIX is under new ownership and is rolling out new core switches. Paul Vixie will give a short summary.

The 6TAP: An IPv6 Exchange

This talk will describe the engineering aspects of the 6TAP, a production IPv6 exchange located at the STAR TAP, a project of ESNet and Canarie/Viaginie. It will discuss 6tap infrastructure, services provided, routing, and policies.

AADS Update

This talk reviews the AADS switch migration and IP renumbering project.

The MAEs

Update on the Ames Exchanges

This presentation will cover the Ames Exchange Points and focus on MAE-West Ames, the Multicast Exchange, the Federal Internet Exchange West (FIX-West), and the Next Generation Internet Exchange-West (NGIX-West). New connectivity options at MAE-West Ames include Fast Ethernet, Channelized Fast Ethernet, and Gigabit Ethernet. A beta program for ATM and POS will also be described.

Speakers
Steve Feldman, MCI WorldCom
Florent Parent, Viaginie
Andrew Schmidt, Ameritech
Lance Tatman, NASA Ames Research Center
Paul Vixie, Internet Software Consortium

Full Abstract

This presentation covers updates related to http://www.radb.net" TARGET="_blank">www.radb.net

Speakers
Craig Labovitz, Microsoft Research

Full Abstract

Are you curious about what it takes to be the local host for a NANOG meeting? Find out everything you always wanted to know (but were afraid to ask) at this BOF, which will be led Randy Bush of Verio, co-host of the May 1999 Eugene NANOG with the University of Oregon. Topics to be covered include:

• Designing and deploying a "rock and roll" network: setting up the network for NANOG, and how the NANOG net compares to installations at IETF
• Working relationship between Merit and the local host
• Resources provided by the local host (connectivity, terminal room, local area network, tech staff)
• Costs for the local host, how much time is required, and how many staff need to be committed to the project
• Resources provided by Merit (meeting coordination, hotel liaison, vendor liaison, tech staff)

Panel members will discuss what they learned from hosting a NANOG and what they wish they'd known before they committed. You'll hear about benefits and problems of hosting for a regional ISP (John Brown, iHighway), an educational institution in a small city (Lucy Lynch, University of Oregon), as well as the planning process and problems/benefits of hosting in a large city (Gregory Soo, Nortel).

Speakers
Moderator - Lucy Lynch, University of Oregon
Panelist - John Brown, iHighway
Panelist - Randy Bush, Verio
Panelist - Pam Ciesla, Merit Network
Panelist - Susan R. Harris, Merit Network
Panelist - Craig Labovitz, Merit Network
Panelist - Gregory Soo, Nortel

Full Abstract

This BOF is targeted for ISPs who are interested in establishing peering relationships. Attendees will have a chance to meet and exchange business cards; Norton will then email participants an Excel spreadsheet with everyone's contact information. The hope is that this will help facilitate peering in the 'net.

Norton will also discuss a forthcoming paper titled "The Peering Decision Tree." Interviews with Internet Service Providers have highlighted three decision phases that customers go through prior to selection of a particular peering solution: identification (traffic engineering data collection and analysis), contact & qualification (initial peering negotiation), and implementation (peering methodology discussion). The first phases identify the who and the why, while the last phase focuses on the how.

The paper is based upon interviews with Internet Service Providers (specifically Peering Coordinators) and documents phases leading up to selection of a peering method and Internet Business Exchange environment. The appendix includes a diagram highlighting key questions asked when identifying peering candidates and determining the method of peering.

 Subject: NANOG 17 Peering BOF Meeting Notes Hi all - I want to thank all of you who participated in the Peering BOF Monday night at the last NANOG meeting in Montreal. It was lively and very productive. To document the BOF, and for the benefit of those who could not attend NANOG, I am sending out my BOF meeting notes. Comments/Corrections welcome. As an aside, I'd like to thank my old colleagues at Merit for inviting me to return to the stage and MC the Montreal NANOG. It was a lot of fun - Thanks! Hope these notes help. Cheers - Bill ============================================================================ Peering BOF - NANOG 17 - Montreal Monday October 4, 1999 7:30 PM EST Moderator: William B. Norton, Equinix, Attendees: About 150? from NANOG meeting The agenda consisted of three items: 1) Ground Rules, 2) Presentation and Discussion of the Peering Decision Tree white paper, and 3) Populating the initial Peering Contact Database to facilitate peering 1) The Ground Rules were ------------------------ A) Not focus on about Peering politics, who gains, etc. B) Not about settlement, nor valuation of peering, etc. C) Instead, Focus on positive things we can do to facilitate peering Capture (document) the essence of peering process 2) Peering Contact Database --------------------------- The Peering Decision Tree interviews (about a dozen) turned up a key challenge ISP Peering Coordinators face: identifying the right staff to speak with at the other ISP. To this end, we helped with this process by having participating Peering Coordinators toss their business cards into the hat. Information they *did not* want in the peering contact database was crossed out. I assembled the cards and e-mailed an excel spreadsheet of all the Peering Coordinators to all the Peering Coordinators that tossed in their cards. .net address for peering, phone numbers, etc.) to [email protected]. I will not send the database to those who do not contribute info to the database, nor folks who are not peering coordinators. I'll send out periodic updates as appropriate.> Naturally, the value of the Peering Contact Database to the community is proportional to the number and type of peering coordinators listed. To help maximize this, I'll try to grow the population of this database by repeating the peering BOF at a variety of forums domestic and international. Suggestions welcome. 3) The Peering Decision Tree Discussion --------------------------------------- The majority of the meeting was focused on the Peering Decision Tree. I interviewed about a dozen ISPs and documented the peering process in the Peering Decision Tree white paper. We walked through the paper in the BOF and validated the decision model; this roughly matches the peering coordinator logic. I started to write up a summary of this part of the meeting and found myself rewriting the paper! To save time, I'm simply including a raw text draft of the peering white paper. (Prettier version (pictures, etc.) available as a word document for those who participate in the Peering Contact Database or are willing to be interviewed/add to the document.) Please consider this a work in progress and send me comments! I'll try and incorporate those comments back into the document for the community. ------------------------------- snip ----------------------------------- Peering Decision Tree William B. Norton DRAFT v 0.7 Abstract -------- Internet Service Provider (ISP) peering is an interconnection business relationship that decreases the cost and reliance on purchased Internet transit. As the single greatest operating expense, ISPs seek to minimize these telecommunications costs. Interviews with Internet Service Providers have highlighted three distinct decision phases of the peering process: Identification (Traffic Engineering Data Collection and Analysis), Contact & Qualification (Initial Peering Negotiation), and Implementation Discussion (Peering Methodology). The first phases identifies the who and the why, while the last phase focuses on the how. The appendix includes a diagram highlighting key questions asked when identifying peering candidates and determining methods of peering. I. Phase 1: Identification of Potential Peer: Traffic Engineering Data Collection and Analysis ---------------------------------------------------------------------------- ---- 

Speakers
Bill Norton, Equinix

Full Abstract

This BOF will allow MPLS-aware and MPLS-curious people to find others like themselves. Have you been wondering about MPLS but been too afraid to ask because of cultural backlash? This MPLS-safe, discrete group will allow you to explore your curiosity in a safe environment. Come find out how a homogeneous IP network can embrace heterogeneous protocols to enhance revenue and network efficiency.

Speakers
Alan Hannan, GlobalCenter

Full Abstract

This talk provides a brief introduction to NANOG, outlines meeting logistics, and introduces two local hosts: Roch Charbonneau of Nortel and Pascal Gosselin of Mlink Internet.

Speakers
Roch Charbonneau, Nortel
Pascal Gosselin, Mlink Internet
Susan R. Harris, Merit Network

Full Abstract

Gilmore and Freedman will suggest ways in which cooperating providers can accept deaggregated prefixes and/or send deaggregated prefixes to one another to allow the use of MEDs and best-exit routing. They will discuss how the deaggregated routes can help increase throughput, and show how the deaggregated prefixes can be confined to your internal network, so as not to leak to the global routing table.

Speakers
Avi Freedman, AboveNet
Patrick Gilmore, PGExpress
Patrick Gilmore is Sr. Network Architect for PGExpress, the ISP subsidiary of Pacific Gateway Exchange. He is building a global IP network that will practice best-exit routing based on some of the ideas presented at the BOF. Gilmore was formerly Sr. Network Engineer at Concentric Networks and Director of Operations at Priori Networks.

Full Abstract

This BOF will provide a forum for providers and users to discuss effective ways to educate new network staff and customers. Topics to be covered include:

• What methods have ISPs used successfully to train and develop routing engineers?
• What initial knowledge do routing engineers need in order to be hired?
• How can customers (both ISP and enterprise) best be trained about how to peer with you -- or when their service does NOT need BGP?
• How do you train sales and other staff to ask the right questions? These questions go beyond BGP, and range across the full spectrum of ISP services, including multihoming, hosting, VPNs, etc.

Strawman topics will include sample courseware and training lab scenarios.

Speakers
Howard Berkowitz, Gett Communications
Howard Berkowitz is Chief Technology Officer for Gett Communications, where he designs high-availability enterprise networks and Internet connectivity, and is developing a simulated exchange point for training. A regular contributor to NANOG tutorials, he is a certified Cisco instructor and author of several RFCs and I-Ds in addressing, multihoming, routing, and VPNs. Berkowitz is part of the ISP training team for INET 2000 and has published two books: Designing Addressing Architectures for Routing and Switching and Designing Routing and Switching Architectures for Enterprise Networks.

Full Abstract

Speakers
Moderator - Edward Kern, Digex
Panelist - Alan Hannan, GlobalCenter
Panelist - Hank Kilmer, Intermedia Communications
Panelist - Andrew Partan, Verio
Panelist - Curtis Villamizar, Avici

Full Abstract

Many network devices provide a wide array of counters and gauges, detailing their operational status. Obtaining this information from the devices is fairly simple using SNMP, netflow, or any other data aquisition method.

The problems start when it comes to storing and analyzing this data. RRDtool can help in this area by providing functions for the storage, processing and presentation of time-series numerical data. RRDtool is also the basis for MRTG3, which is currently under development by Oetiger.

In this talk you will learn how RRDtool works and how you can use it to solve your monitoring problems.

Speakers
Tobias Oetiker, CAIDA
After earning a Masters degree in Electrical Engineering from the Swiss Federal Institute of Technology in 1994, Oetiker spent most of his professional life managing Unix systems, first in England, and, since 1995, at the Swiss Federal Institute of Technology in Zurich. Mostly on his own time he wrote large parts of MRTG, a tool some ISPs seem to like quite a lot for producing management-friendly graphs of their network traffic.

Full Abstract

Remstats is a system of perl-scripts using Tobi Oetiker's RRDtool to perform network and server monitoring. RRDtool supplies the database and graphing functions, and remstats supplies the data-collection and Web-page generation.

Remstats was designed to collect data from various sources, including, but not limited to, SNMP. The tool produces Web pages with multiple graphs per page, as I wanted to be able to correlate information between graphs. It also produces configurable alerts based on any data that is being collected.

Speakers
Thomas Erskine, Communications Research Centre

Full Abstract

An overview of the different means to provision WAN bandwidth to meet needs higher than T1 but lower than DS3. The presentation will review Load Balancing, physical layer inverse multiplexing, subrate DS3, ATM AIM, Multi-Link PPP, and Multi-Link Frame Relay.

Speakers
Joshua Sakov, Tiara Networks

Full Abstract

Finding the source of forged IP datagrams in a large, high-speed network is difficult due to the design of the IP protocol and the lack of sufficient capability in most high-speed, high-capacity router implementations. Typically, not enough of the routers in such a network are capable of performing the packet forwarding diagnostics required for this task. As a result, tracking down the source of a flood-type denial-of-service (DoS) attack is usually difficult or impossible.

CenterTrack is an overlay network, consisting of IP tunnels, that is used to selectively reroute interesting datagrams directly from edge routers to special tracking routers. The tracking routers can easily determine the ingress edge router by observing which tunnel the datagrams arrive on. The datagrams can be examined, then dropped or forwarded to the appropriate egress point.

This system simplifies the work required to determine the ingress adjacency of a flood attack while bypassing any equipment which may be incapable of performing the necessary diagnostic functions.

Speakers
Robert Stone, UUNET

Full Abstract

Speakers
Susan R. Harris, Merit Network