^ Top

NANOG Meeting Presentation Abstract

Tutorial: Routing Policy Specification Language/IRR
Meeting: NANOG17
Date / Time: 1999-10-03 1:00pm - 4:00pm
Room: Alfred Roulau B
Presenters: Speakers:
Cengiz Alaettinoglu, ISI.
Gerald Winters, Merit Network/Arbor Networks.
Abstract: This tutorial introduces the Internet Routing Registry (IRR) and the Routing Policy Specification Language (RPSL). We explain how to register and query routing policy objects in the IRR. After a brief introduction to routing policies, we discuss RPSL, the new IETF-proposed standard language for specifying Internet routing policies. RPSL is currently being deployed by IRR participants and will replace RIPE-181, the current IRR routing policy specification language. RPSL provides substantial extensions to RIPE-181, making it possible to specify a much richer set of routing policies in a more concise manner. In addition, we present and demonstrate several IRR policy analysis tools, including RtConfig to configure routers, and roe to reconcile route objects with actual routes in the Internet.
Files: None.
Sponsors: None.
Tutorial: Introduction to MPLS
Meeting: NANOG17
Date / Time: 1999-10-03 1:00pm - 3:00pm
Room: Alfred Roulau A
Presenters: Speakers:
Peter Ashwood-Smith, Nortel.
Abstract: This tutorial introduces concepts of Multi Protocol Label Switching, including:

  • Overview of MPLS

  • Label Encapsulations

  • Label Distribution Protocols

  • MPLS & ATM

Constraint Based Routing with CR-LDP and RSVP
Files: pptIntroduction to MPLS(PPT)
Sponsors: None.
Tutorial: Deploying Distributed Content Caching in Large IP Networks
Meeting: NANOG17
Date / Time: 1999-10-03 3:30pm - 5:30pm
Room: Alfred Roulau A
Presenters: Speakers:
Andrew Khoo, Versatel Telecom.
Adrian Chadd, Versatel Telecom.
Abstract: This tutorial is intended to introduce the concept of large-scale caching spanning multiple POPs and regions. Topics to be covered include:

  • Cache building blocks

  • POP design for efficient caching

  • Extending caching to multiple pops

  • Designing a rational cache hierachy

  • Using satellite as a pre-feeding mechanism

  • Case studies from a large US-EU network
  • Q&A regarding caching

Files: pptAdrian Chadd Presentation(PPT)
Sponsors: None.
Tutorial: OSPF Goodies for ISPs
Meeting: NANOG17
Date / Time: 1999-10-03 3:30pm - 5:30pm
Room: Picardie A/B
Presenters: Speakers:
Howard Berkowitz, Gett Communications.
Abstract: After an introductory overview of the OSPF interior routing protocol, Berkowitz presents some interesting case studies of useful but non-obvious things one can do with OSPF, if one is willing to think \"outside the box.\" The tutorial concentrates on determining requirements and network design, rather than detailed configuration, emphasizing ways that a high-powered OSPF domain can be a viable alternative to BGP for many customer and internal ISP applications. Also includes information about network deployment and practical address management with OSPF.
Files: pdfOSPF Goodies for ISPs(PDF)
pptOSPF Goodies for ISPs(PPT)
Sponsors: None.
Welcome, Introductions, Future Meetings
Meeting: NANOG17
Date / Time: 1999-10-04 9:00am - 9:15am
Presenters: Speakers:
Susan R. Harris, Merit Network.
Roch Charbonneau, Nortel.
Pascal Gosselin, Mlink Internet.
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.
Files: pptIntroductions(PPT)
Sponsors: None.
Building Network Monitoring Systems with RRDtool
Meeting: NANOG17
Date / Time: 1999-10-04 11:00am - 11:45am
Presenters: 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.
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.
Files: youtubeBuilding Network Monitoring Systems with RRDtool
pdfBuilding Network Monitoring Systems with RRDtool(PDF)
Sponsors: None.
Using Remstats for Network and Server Monitoring
Meeting: NANOG17
Date / Time: 1999-10-04 11:45am - 12:00pm
Presenters: Speakers:
Thomas Erskine, Communications Research Centre.
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.
Files: pptUsing Remstats(PPT)
youtubeUsing Remstats for Network and Server Monitoring
Sponsors: None.
Managing Multicast Services - A User\'s View
Meeting: NANOG17
Date / Time: 1999-10-04 1:30pm - 2:00pm
Presenters: Speakers:

John Robinson, Communications Research Centre

Dr. John Robinson has been involved with the Internet since the first connection was made to Canada in the early 1980s. He re-joined the Communications Research Centre in Ottawa in 1995 after a decade in Europe, where he worked in Holland at a high-tech think-tank conducting research, design and prototyping of computer networks for NATO \"Command and Control.\" Currently he is the Head of Distributed Systems Research at the CRC, where his research interests include performance analysis and quality-of-service issues with next generation Internet technologies.
John Stewart, Communications Research Centre.
Abstract: The Communications Research Centre (CRC) has been participating, since 1995, in MBone R&D projects with a consortium of European research organisations and industries under the European Union Framework 4 Telematics Programme. A CRC objective has been to make the MBone videoconferencing technology usable for non-experts.

Not enough attention has been paid to the monitoring and diagnostic tools that are needed to manage the emerging real-time multicast network infrastructure. With the interests and needs of the non-expert end-user in mind, we have been looking at the existing MBone monitoring tools and have designed new tools to be added to the existing suite. Tools for IP multicast monitoring (MReceipt; MultiMON) and for QoS performance diagnostics (MERCInari) have been designed and prototypes have been implemented and tested on the MBone with the support of our research partners. This presentation will present some of the ideas and observations arising from our research, and describe and demonstrate the prototype tools that have been developed.
Files: pptJohn Robinson Presentation(PPT)
Sponsors: None.
Optical Networks for the Rest of Us: Recent Developments in Canada\'s Research Networks
Meeting: NANOG17
Date / Time: 1999-10-04 2:00pm - 2:45pm
Presenters: Speakers:

Bill St. Arnaud, CANARIE

Bill St. Arnaud is Senior Director of Network Projects for CANARIE Inc., an industry government consortium to promote and develop information highway technologies in Canada. At CANARIE, he has been responsible for the coordination and implementation of the world\'s first national optical R&D Internet network, CA*net 3. Arnaud is a frequent guest speaker at conferences on the Internet and optical networking, and is a regular contributor to several networking magazines.
Abstract: CA*net 3 is an 8500 km IP/DWDM network which was built as a production network for the research and education community in Canada. The network started operations in October 1998 and as such is one of the oldest IP/DWDM networks in the world. The presentation will discuss the practical issues of building an IP/DWDM network, including:

  • Maintaining power levels between wavelengths

  • Network monitoring and management at the optical transport level

  • Initial trials to use MPLS for traffic engineering and restoral and protection

  • Interoperability issues with DWDM transport equipment

  • The presentation will also briefly cover new extensions to the network in Newfoundland and Alberta to build a 1700 km Gigabit Ethernet/DWDM network and a 800 km Gigabit Ethernet/CWDM (Coarse Wave Division) network. The latter two developments, plus the deployment of dark fiber by the research networks in Canada, promise to radically reduce the cost of transport networks for ISPs.
Files: pptBill St. Arnaud Presentation(PPT)
Sponsors: None.
The HOW-TO Guide to Building Your Own Fiber Network: An ISP Perspective
Meeting: NANOG17
Date / Time: 1999-10-04 2:45pm - 3:30pm
Presenters: Speakers:
Yves Le Borgne, RISQ.
Robert Proulx, IMS Expert Conseils.
Abstract: For the past three years, RISQ has been actively involved in building a privately owned fiber network for the benefit of Quebec\'s Research and Education community. The effort was spurred by our realization of the fact that ownership was a viable alternative to broadband network leasing. Our current accomplishments include a MAN in Montreal, a MAN under construction in Quebec city, and intercity transport spanning the major cities in the province. We are also currently working with universities, colleges, and school boards to build institutional networks that leverage our existing network, and allow us to expand to new areas.

The talk will focus on three principal areas. Firstly, we will discuss the business rationale for building our network, including comparisons between leasing and ownership. Secondly, we will explain the strategies used by RISQ so far to gain access to right of ways, and how these strategies have been contributors to the financial business case. In particular, we will expand on the notion of fiber optic brokerage, and how we have been able to leverage industry\'s capabilities to enhance our ability to act for schools and research centers in Quebec and elsewhere in Canada. Finally, we will expand on future plans and strategies with regards to fiber brokerage and deployment in the Canadian regulatory context.

Although this talk will be given from the persepctive of building dark fiber networks for th R&E community in Quebec, many of the lessons learned can be adapted by ISPs who are interested in building their own dark fiber networks.
Files: pptThe How-To Guide to Building Your Own Fiber Network(PPT)
Sponsors: None.
News from the Exchange Points
Meeting: NANOG17
Date / Time: 1999-10-04 3:45pm - 4:45pm
Presenters: Speakers:
Paul Vixie, Internet Software Consortium.
Florent Parent, Viaginie.
Andrew Schmidt, Ameritech.
Steve Feldman, MCI WorldCom.
Lance Tatman, NASA Ames Research Center.
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.
Files: pdfPaul Vixie Presentation(PDF)
Sponsors: None.
Update on the RADB Internet Routing Registry Service
Meeting: NANOG17
Date / Time: 1999-10-04 4:45pm - 5:00pm
Presenters: Speakers:
Craig Labovitz, Microsoft Research.
Abstract: This presentation covers updates related to www.radb.net
Files: None.
Sponsors: None.
Peering BOF
Meeting: NANOG17
Date / Time: 1999-10-04 7:30pm - 9:00pm
Room: Alfred Rouleau A
Presenters: Speakers:
Bill Norton, Equinix.
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 -

Hope these notes help. Cheers -


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

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
Choices made by Internet Service Providers (ISP) are often dominated by
telecommunications cost issues. Highest among these costs are Internet
transit costs that provide the ISP with connectivity to the global
Internet. Transit Prices for DS-3 transit for example vary by circuit mile
but can be as high as \$50,000/month, and OC-3 transit can cost up to
$150,000/month . To reduce these costs, ISPs seek peering (-zero or reduced
cost) relationships with other ISPs that provide more direct traffic
exchange and reduce the load on these expensive transit services (as shown

To identify potential peers, ISPs use a variety of criteria. There may be
existing business relationships that can be leveraged to include peering.
Quantities of traffic distributed between networks often set the pace of
the negotiation; to quantify this, ISPs may systematically sample inbound
and outbound traffic flows. Flows then are mapped to originating AS, and
calculations are made to determine where peering (direct interconnections)
would most reduce the load on the expensive transit paths. There is
substantial work involved here, as this traffic sampling results in a large
number of data. The end result of this first phase is list of the top ISP
candidates for peering.
The greatly simplified peer qualification decision tree looks something
like this:

Once the measurements have been made and analyzed, and it appears to be of
benefit to peer,, the ISP enters into Phase 2, Contact & Qualification,
Initial Peering Negotiation.

II. Phase 2: Contact & Qualification, Initial Peering Negotiation
Internet Service Providers typically have a person or group specifically
tasked with peering and traffic engineering issues. For example, UUNet has
a \"Peering Steering Committee\" to evaluate peering requests. Some
variations of the following steps lead to the parties either leaving the
negotiation or proceeding to peering methodology discussions.

The first step is for one of the parties to initiate contact with the
potential peer. Today, discussion starts in one of the following ways:
a) as part of a larger business transaction,
b) via electronic mail, using the pseudo standard [email protected]
or a personal contact,
c) from contacts listed on an exchange point participant list,
d) with tech-c or admin-c from DNS or ASN registries,
e) informal meeting in an engineering forum like NANOG, IETF, RIPE, etc.,
f) at trade shows from introductions among speakers, or with booth staff,
g) from the target ISP sales force,
h) from the target ISP NOC.

The interviews to date have highlight a key challenge for ISPs: finding the
right person to speak with is a difficult and time intensive process.
Mergers and acquisitions further cloud lines of communication. This is
where \"people networking\" helps a great deal, and hiring experience for
their contacts speeds this initial contact process up quite a bit.

Second, mutual non-disclosures may be negotiated and signed, and a
discussion of peering policy and prerequisites follow. Traffic engineering
discussions and data disclosure may be used to justify the peering
relationship. Each ISP typically has a set of requirements for peering that
include peering at some number of geographically distributed locations,
sometimes at public exchange points.
Traffic volume is usually a key determining factor. The decision rule
hinges upon whether or not there is sufficient savings from peering to
justify spending capital on a port on a router and/or a portion of the
interconnection costs or augmenting existing capacity into an exchange
point. A Bilateral Peering Agreement (BLPA) is the legal form that details
each parties understanding of acceptable behavior, and defines the arms
length interactions that each would agreed to.

Another motivation for peering to factor in includes lower latency and/or
more regional distribution of traffic than existing connections allow.
This process is diagrammed below.

After this initial discussion, either party may decide to walk away from
peering discussions until certain criteria are met . If both parties agree
that their requirements are met sufficiently to discuss methodology, and
they both benefit from the peering relationship, they move onto Phase 3:
Implementation Discussions.

III. Phase 3: Implementation Discussions: Peering Methodology
Since peering is of mutual benefit, both parties next explore the
interconnection method(s) that most effectively exchange traffic to and
from each other\'s customers. The primary goal is to establish mutual
point(s) of interconnection, and secondarily detail optimal traffic
exchange behavior (MEDs).
For interconnections, ISPs face three options: Direct Circuit
Interconnection, Exchange-Based Interconnection or some global combination

The \"Interconnection Strategies for ISPs\" white paper quantifies the
economics and technical tradeoffs between the first two options. To
summarize this report, the preferred methodology depends on the number of
peers participating in the region and bandwidth required for its regional
interconnections. ISPs that expect to interconnect at high or rapidly
increasing bandwidth within the region, or expect interconnections with
more than five parties in the region often prefer the exchange-based
solution. Those that do not anticipate a large number of regional
interconnects prefer direct-circuits and typically decide to split the
costs of interconnection with the peer by region. On occasion the costs
are covered in whole by one peer.

For direct-circuit interconnects, key issues center upon interconnection
location(s) and who pays for and manages the interconnection. This becomes
a material cost issue as traffic grows and circuits increase in size and
In either case, ISPs generally have the following goals for establishing
1. fulfill obligations of larger business agreement,
2. get peering set up as soon as possible,
3. minimize the cost of the interconnection and their transit costs,
4. maximize the benefits of a systematic approach to peering, and
5. execute the regional operations plan as strategy dictates (may be
architecture/network development group goal).

Exchange Environment Selection Criteria
From this point on the focus will be on the more scalable of the two
approaches (the exchange-based interconnection method) and describe the
selection criteria an ISP typically uses when selecting an exchange. Note
that these issues are listed in no particular order.

Telecommunications Access Issues
How fast can circuits be bought into the interconnection environment? How
many carriers compete for my business for circuits back to my local Point
of Presence (POP)? For facilities-based ISPs, what is the cost of trenching
into the exchange (how far away and what obstacles present themselves)? Are
there nearby fiber providers that lease strands? These answers will answer
the most important question to ISPs: How fast can my peer and I get
connectivity into the exchange? Multiple carriers lead to speed and cost
efficiencies. Some ISPs have volume deals with certain carriers or
otherwise preferred carriers so prefer exchanges where these carriers can
quickly provision circuits. These answers strongly impact the desirability
of the exchange environment.

Deployment Issues
How do I get my equipment into the exchange (assuming it supports
collocation)? Do I ship equipment in or do I have to bring it with me as I
fly in? Will someone act as remote hands and eyes to get the equipment into
the racks or do I do the installation myself? What are the costs associated
with deployment (travel, staff time, etc.)? Does the exchange have
sufficient space, power. The answers to these questions impact the
deployment schedule for the ISP engineers and the costs of the
interconnection method.

ISP Current Presences
The most inexpensive (and expedient) peering arrangements are the ones made
between ISPs that are already located in the same exchange with sufficient
capacity to interconnect. Cross-connects or switching fabrics can easily
establish peering within hours or at most days. ISPs will prefer to
interact where one of both ISP already has a presence. Somewhat related,
is the exchange in the right geographic location?

Operations Issues
Once the ISP equipment and/or circuit into the exchange is installed, these
issues focus on the ongoing operations activities allowed within the
exchange. Does the exchange allow private network interconnections? Are
there requirements to connect to a central switch? How secure is the
facility? Is there sufficient power, HVAC, capacity at the switch, space
for additional racks, real time staff support? Is it easy to upgrade my
presence over time? Upgrading in this context means the ability to increase
the speed of circuits into the exchange, the ability to purchase dark
fiber, the ability to increase the number of racks and cross connects in
the exchange, the ease of increasing the speed of interconnection. ISPs
will prefer bandwidth-rich, ISP-friendly exchanges over those with
restrictions over future operations.

Business Issues
Perhaps the most far-reaching issue is strategic: do we want to support
this exchange operator, and do their interests enhance or conflict with ours?
According to Lauren Nowlin, Peering Coordinator at PGExpress, \"Bandwidth,
strategic partner alliances, and corporate ties often override the
technical justification .\" Will using this exchange support a competitor
(contribute to their net income, their credibility, their positioning)?
Does the exchange have requirements (require use of their carrier or ISP
services) that limit the market for services within the exchange? Since it
is difficult and disruptive to move equipment out of an exchange, ISPs will
prefer a neutrally operated exchange environment that doesn\'t suffer from
market distortions and limitations due to business conflicts of interest.

Cost Issues
What is the cost of using this exchange? What are the rack fees, cross
connect fees, port fees, installation fees? What are the future operating
fees going to be? What are the motivations and parameters surrounding these
fees? Cost issues shadow most of the other issues listed in this paper. All
else being equal, ISPs will seek to minimize the costs, particularly
upfront costs, associated with the interconnection for peering.

Credibility Issue
Does the exchange exist today and will it exist tomorrow? Who will be there
in the future? The benefit to the ISP grows (as pictured below) as the
number of interconnection possibilities grow, as the number of transit
customers grows, and as the bandwidth between the exchange participants
grow. During the early stages of the exchange, ISPs are asked to make a
leap of faith when committing, and therefore prefer an exchange with strong
backing and the credibility to ensure the ISP obtains value.

Does the exchange operator have the backing and credibility to attract the
more valuable peering candidates? Who is managing the exchange and what
technology is in use signals the credibility and survivability of the
exchange. ISPs will prefer an exchange with credibility - one that is
financially and technically well backed and likely to attract the most
desirably peering candidates.

Exchange Population
Are there other side benefits to using this exchange? Are there other ISPs
there that are peering candidates? Are there transit sales possible at the
exchange? In the context of the credibility issue discussed above, who will
likely be at the exchange in the future, and when will the cost of
participation equal the value of the interconnection (also known as the
Critical Mass Point)? ISPs will prefer established and well-populated
exchanges, particularly those with potential customers that can generate
revenue for the ISP.

Existing Exchange vs. New Exchange?
There are many regional \"meet me\" exchange points in each region of the
U.S. There are also emerging exchanges that may be considered. However,
given the pace of ISP expansion, it is unlikely that emerging exchange
offerings are differentiated or compelling enough to be preferred over
existing exchanges. Chronic traffic congestion can influence the decision
to plan to peer in an existing exchange or wait until a better exchange
opens. Customers with heavy flows of regional traffic can also influence
the decision. Long term benefits (scalability) may lead to preferring a
next generation exchange. However, all else considered equal, ISPs
generally prefer an existing exchange to an emerging one.

This third discussion phase can be summed up by the following graph.

IV. Summary
The paper provides a rough description of the decision process ISPs follow
to obtain peering relationships and reduce their transit costs. It focuses
on the elements of the decision that lead to the selection of a specific
exchange environment for peering.

The results of the interviews with ISP Peering Coordinators can be
summarized with the following observations:
1) To reduce transit costs, peering goals for ISPs include a) to get
peering set up as soon as possible, b) to minimize the cost of peering, c)
to maximize the benefits of whatever architecture is selected, and d) to
leverage the architecture to accomplish their strategic regional goals.
2) The selection of an exchange is made relatively late in the peering
process, and the selection of a soon-to-be-available exchange is a very
difficult sell. This is particularly true when there are existing exchanges
in the region that meet the ISPs requirements.
3) Most critical to the ISP are issues surrounding business opportunities
presented at an exchange, telecommunications access, deployment,
population, operations, cost, and credibility. ISPs will prefer and
exchange environment that best suit these needs.
4) One major challenge facing Peering Coordinators is the identification of
potential peers and initiating discussions.

This paper was the result of interviews with key Internet peering
coordinators, interactions with ISP support staff, and side conversations
at various meetings and forums. Special thanks to a few folks who
contributed their time and ideas to help create this early draft report:
Ren Nowlin (PGExpress/Onyx), Joe Payne (IXC), Dave Diaz (Netrail), Jake
Khuon and Alan Hannan (Frontier GlobalCenter), Dan Gisi and Jeff Rizzo
(Equinix), Patricia Taylor-Dolan (Level 3 Communications), Sean Donelan
(AT&T Labs). As interviews continue, this list will expand to identify
other key contributors to this paper.

[1] \"Maturation in a Free Market: The Changing Dynamics of Peering in the
ISP Market\" by Jennifer DePalma
[2] \"NAPs, Exchange Points, and Interconnection of Internet Service
Providers: Recent Trends, Part I: 1997 Survey of Worldwide NAPs and
Exchange Points\", Mark Knopper

Appendix A: Peering Decision Tree
Appendix B: Detail Peering Decision Tree

Some interesting side notes from the BOF
+At least two countries including Israel have regulators that forced ISPs
to peer.
+Formal legal documents are not required for peering, although commonplace
+Keith Mitchel (LINX) has a prototype Bi_Lateral Peering Agreement (BLPA)
+The group wanted the Peering Contact Database NOT to be public, but rather
limited to the folks participating.
+Non-U.S. ISPs seem to have greater difficulty establishing peering here in
North America. Language, culture issues are mixed with technical issues.

Peering BOF Slides
Files: docPeering Decision Tree (Full paper in MS Word, updated 1/11/00)(DOC)
Sponsors: None.
How to Be a Local NANOG Host
Meeting: NANOG17
Date / Time: 1999-10-04 7:30pm - 9:00pm
Room: Alfred Rouleau B
Presenters: Moderators:
Lucy Lynch, University of Oregon.
Randy Bush, Verio.
Gregory Soo, Nortel.
John Brown, iHighway.
Pam Ciesla, Merit Network.
Craig Labovitz, Merit Network.
Susan R. Harris, Merit Network.
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).
Files: None.
Sponsors: None.
MPLS BOF - Vendors, Deployment, and Practice
Meeting: NANOG17
Date / Time: 1999-10-04 7:30pm - 9:00pm
Room: Anjou A/B
Presenters: Speakers:
Alan Hannan, GlobalCenter.
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.
Files: None.
Sponsors: None.
Inter-Provider Cooperation for MEDs and Best-Exit Routing
Meeting: NANOG17
Date / Time: 1999-10-04 9:00pm - 9:45pm
Room: Alfred Rouleau A
Presenters: Speakers:

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.
Avi Freedman, AboveNet.
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.
Files: None.
Sponsors: None.
Conveying Clue: Educating New Staff and Customers
Meeting: NANOG17
Date / Time: 1999-10-04 9:00pm - 10:30pm
Room: Alfred Rouleau B
Presenters: 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: <I>Designing Addressing Architectures for Routing and Switching and Designing Routing and Switching Architectures for Enterprise Networks.</I>
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.
Files: pptConveying Clue(PPT)
Sponsors: None.
Content-Friendly Caching: A Content Hoster\'s Guide to the HTTP/1.x Specifications
Meeting: NANOG17
Date / Time: 1999-10-05 9:00am - 9:30am
Presenters: Speakers:

Solom Heddaya, InfoLibria

Abdelsalam \'Solom\' Heddaya, VP for Research & Architecture at InfoLibria, has more than 15 years research experience in caching and replication. As former associate professor of Computer Science (CS) at Boston University, Heddaya led the development of the advanced technology that initiated InfoLibria. He holds a Ph.D. in CS from Harvard University and regularly publishes and speaks on new technology fundamentals.
Abstract: The HTTP/1.x protocol specs contain many features that affect the networks over which content flows. This presentation will review these features, and discuss the extent to which they are supported by popular Web servers and by products that handle Web content in general.

Knowledge of the issues covered here is going to be required by service providers who wish to extend their offerings from connectivity to content-based services. We will also touch upon content types that are not addressed by HTTP/1.x, such as streaming media, back-end databases and game servers.
Files: None.
Sponsors: None.
Panel: Current and Next-Generation Content Distribution Techniques
Meeting: NANOG17
Date / Time: 1999-10-05 9:30am - 10:45am
Presenters: Moderators:

Bill Norton, Equinix

As Co-Founder and Director of Business Development at Equinix, Bill Norton focuses his attention on building strategic relationships among companies participating at the Internet Business Exchanges. Previously, he was the Chair of NANOG and Manager of the Internet Engineering Group at Merit, leading a variety of national and international network research and operations projects.

Evan Baer, SkyCache

Evan Baer is a senior engineer at SkyCache. Before joining SkyCache, Baer consulted on Internet projects for DEC and Time Warner, and was a partner in Evolution, a software development firm in New York City.

Peter Danzig, Akamai

Holly Pease joined Digital Island in 1997 as Director of Network Engineering. Prior to her role at Digital Island, Holly designed and implemented networks worldwide for Visa International, including Visa\'s Secure Electronic Transactions (SET) infrastructure.
Holly Pease, Digital Island.
Abstract: Content distribution methods include techniques such as:

  • Making DNS resolution dependant on topological distance

  • Assigning a single IP address for multiple machines routed according to some metric

  • Backing multicasting off to unicasting, based upon encountered congestion

  • \"Best routing, least congested path application-layer routing\"
    Hashing algorithms/randomized content distribution

Although each of these higher-layer techiques makes decisions based upon assumptions and measurements of ISP services, the Content Distributor and ISP communities haven\'t yet discussed these techniques in an open forum. This panel discusses the validity of these assumptions, the implementation of various content distribution techniques, and the impact of those technicques on the infrastructure.

Topics discussed include how various content distribution systems work, what dynamics the techniques take into account, what measurements are made to make the distribution decision, and what results validate the performance of the various distribution techniques.
Files: pptEvan Baer Presentation(PPT)
Sponsors: None.
BIND and DNS: The Moving Targets
Meeting: NANOG17
Date / Time: 1999-10-05 11:15am - 11:30am
Presenters: Speakers:

Paul Vixie, Internet Software Consortium

Paul Vixie is the main author of BIND and of several DNS-related RFC\'s. His other accomplishments include the authorship of \"cron\" and \"rtty\", the formation of Internet Software Consortium, Inc. and Mail Abuse Prevention System, LLC, and convincing DEC to let him and his gang build things like gatekeeper.dec.com and the Palo Alto Internet Exchange.<BR> <BR> His current day job is CEO of M.I.B.H., LLC, an network operations company in Redwood City, California, whose customers include Altavista as well as parts of Compaq and Microsoft. He is also on the board of directors of a half-dozen or so network-related companies. He lives in the Bay Area with his wife, three children, two cats, one dog, and a lot of gophers.
Abstract: ISC will present a status report on BIND and DNS.
Files: None.
Sponsors: None.
Analysis and Experimental Measurements of Internet BGP Convergence Latencies
Meeting: NANOG17
Date / Time: 1999-10-05 11:30am - 12:00pm
Presenters: Speakers:
Craig Labovitz, Microsoft Research/Merit.
Abha Ahuja, Merit Network.
Abstract: In this talk, we provide analysis and data from a sixteen-month study of Internet BGP route convergence latencies. We first describe our experimental instrumentation of the Internet, which included a number of geographically and topologically diverse BGP fault injection and route collection probe machines. We then describe the measured response of BGP after several types of routing events, including single route failures, multi-homed fail-over, and route restoral. We provide analysis and a brief theoretical description of expected and worst-case BGP convergence behaviors. Finally, we dispel several tenets of conventional networking wisdom about BGP and routing convergence.
Files: pptCraig Labovitz Presentation(PPT)
Sponsors: None.
Filling the Gap: Provisioning Bandwidth Between T1 and T3
Meeting: NANOG17
Date / Time: 1999-10-05 1:30pm - 2:00pm
Presenters: Speakers:
Joshua Sakov, Tiara Networks.
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.
Files: None.
Sponsors: None.
CenterTrack: An IP Overlay Network for Tracking DoS Floods
Meeting: NANOG17
Date / Time: 1999-10-05 2:00pm - 2:45pm
Presenters: Speakers:
Robert Stone, UUNET.
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.
Files: pptRobert Stone Presentation(PPT)
Sponsors: None.

Back to NANOG17 agenda.

NANOG17 Abstracts

  • News from the Exchange Points
    Paul VixieInternet Software Consortium; .
    Florent ParentViaginie; .
    Andrew SchmidtAmeritech; .
    Steve FeldmanMCI WorldCom; .
    Lance TatmanNASA Ames Research Center; .
  • News from the Exchange Points
    Paul VixieInternet Software Consortium; .
    Florent ParentViaginie; .
    Andrew SchmidtAmeritech; .
    Steve FeldmanMCI WorldCom; .
    Lance TatmanNASA Ames Research Center; .
  • News from the Exchange Points
    Paul VixieInternet Software Consortium; .
    Florent ParentViaginie; .
    Andrew SchmidtAmeritech; .
    Steve FeldmanMCI WorldCom; .
    Lance TatmanNASA Ames Research Center; .
  • News from the Exchange Points
    Paul VixieInternet Software Consortium; .
    Florent ParentViaginie; .
    Andrew SchmidtAmeritech; .
    Steve FeldmanMCI WorldCom; .
    Lance TatmanNASA Ames Research Center; .
  • News from the Exchange Points
    Paul VixieInternet Software Consortium; .
    Florent ParentViaginie; .
    Andrew SchmidtAmeritech; .
    Steve FeldmanMCI WorldCom; .
    Lance TatmanNASA Ames Research Center; .
  • How to Be a Local NANOG Host
    Lucy LynchUniversity of Oregon; .
    Randy BushVerio; .
    Gregory SooNortel; .
    John BrowniHighway; .
    Pam CieslaMerit Network; .
    Craig LabovitzMerit Network; .
    Susan R. HarrisMerit Network; .
  • How to Be a Local NANOG Host
    Lucy LynchUniversity of Oregon; .
    Randy BushVerio; .
    Gregory SooNortel; .
    John BrowniHighway; .
    Pam CieslaMerit Network; .
    Craig LabovitzMerit Network; .
    Susan R. HarrisMerit Network; .
  • How to Be a Local NANOG Host
    Lucy LynchUniversity of Oregon; .
    Randy BushVerio; .
    Gregory SooNortel; .
    John BrowniHighway; .
    Pam CieslaMerit Network; .
    Craig LabovitzMerit Network; .
    Susan R. HarrisMerit Network; .
  • How to Be a Local NANOG Host
    Lucy LynchUniversity of Oregon; .
    Randy BushVerio; .
    Gregory SooNortel; .
    John BrowniHighway; .
    Pam CieslaMerit Network; .
    Craig LabovitzMerit Network; .
    Susan R. HarrisMerit Network; .
  • How to Be a Local NANOG Host
    Lucy LynchUniversity of Oregon; .
    Randy BushVerio; .
    Gregory SooNortel; .
    John BrowniHighway; .
    Pam CieslaMerit Network; .
    Craig LabovitzMerit Network; .
    Susan R. HarrisMerit Network; .
  • How to Be a Local NANOG Host
    Lucy LynchUniversity of Oregon; .
    Randy BushVerio; .
    Gregory SooNortel; .
    John BrowniHighway; .
    Pam CieslaMerit Network; .
    Craig LabovitzMerit Network; .
    Susan R. HarrisMerit Network; .
  • How to Be a Local NANOG Host
    Lucy LynchUniversity of Oregon; .
    Randy BushVerio; .
    Gregory SooNortel; .
    John BrowniHighway; .
    Pam CieslaMerit Network; .
    Craig LabovitzMerit Network; .
    Susan R. HarrisMerit Network; .


^ Back to Top