^ Top


NANOG 24 Agenda 

Presentation File Key:

Windows Media video, requires Windows Media Player to view. 
Real Video, requires Real Player to view. 
PDF Document, requires Adobe Acrobat Reader to view/print. 
Sunday, February 10 2002
Time/Webcast:Room:Topic/Abstract:Presenter/Sponsor:Presentation Files:
1:30pm - 3:00pmChopin Ballroom

Tutorial: Inter-domain Traffic Engineering: Principles, Applications, and Case Studies

The Internet is a mesh of interconnected networks, each striving to control its network operating costs, optimize end-to-end performance for customers, and differentiate its IP services from those of competing providers. Increasingly, a provider\'s success will be determined by its ability to monitor and engineer its inter-domain traffic performance.<BR> <BR> Traditional traffic engineering (TE) techniques focus on intra-domain control features, particularly those associated with multi-protocol label switching (MPLS) within an infrastructure. Newer traffic monitoring and analysis solutions are supporting collection and correlation of multiple network metrics, specifically, inter-domain routing, traffic and path performance data. The emerging traffic engineering systems are oriented toward goals of optimizing network performance while controlling costs associated with operations at the edges of networks, i.e., the points where traffic is exchanged with other networks.<BR> <BR> This tutorial provides an overview of techniques that can be used by networks to expand visibility into and control of traffic moving between their network and other domains. The focus is on analysis methodologies and case examples of how inter-domain TE can be used by networks to support cost-effective peering analysis and planning for new capacity and services, as well as real-time routing and traffic management.

View full abstract page.

  • Joe Abley, PAIX
  • Joe Abley is a toolmaker at MFN, building tools to measure, manage and document MFN\'s IP network; he has also worked at MFN as a backbone engineer. Before joining MFN, Joe worked as a consultant for various carriers and ISPs in New Zealand, where he provided operational and network design support for regional IP networks.

  • Josh Wepman, Ixia
  • Josh Wepman is an applications engineer at Ixia, defining applications for the IxTraffic traffic engineering product. Josh was a senior engineer at Caimis, Inc., responsible for BGP routing and traffic (flow) analyses and for design of several traffic engineering applications. Previously, he served as a backbone engineer at UUNET, managing intra-domain routing and traffic engineering efforts.
youtubeInter-domain Traffic Engineering: Principles, Applications, and Case Studies
pptTraffic Engineering(PPT)
1:30pm - 3:00pmSandringham Room

Tutorial: IS-IS Deployment & Design Guidelines, with Emphasis on New Features

Level: intermediate The presentation discusses IS-IS deployment scenarios (L1-Only, L2-Only, L1 & L2 with route-leaking), design consisderations, and features that have been added recently to the IS-IS protocol, such as route-leaking, route-tags, and extensions to MPLS-TE. An outline follows: <UL> <LI> Introduction <UL> <LI> Agenda</LI> <LI> Scope of the presentation <BR><BR></LI> </UL> </LI> <LI> Depoloyment Scenarios <UL> <LI> L1-Only</LI> <LI> L2-Only</LI> <LI> L1 & L2 with Route-Leaking <BR><BR></LI> </UL> </LI> <LI> Design Considerations <UL> <LI> Set overload bit</LI> <LI> LSP flooding</LI> <LI> Exponential back-off</LI> <LI> SPF, PRC, LSP generation</LI> <LI> Hello padding</LI> <LI> Database timers</LI> <LI> Non-adverstisement of parallel adjacencies in the LSP <BR><BR></LI> </UL> </LI> <LI> New Features <UL> <LI> Route-leaking</LI> <LI> Extensions to MPLS-TE</LI> <LI> Fast hellos</LI> <LI> dCEF and IS-IS</LI> <LI> Route-tags</LI> <LI> p2p adjancencies over broadcast media <BR><BR></LI> </UL> </LI> <LI> Suggested reading </LI> </UL>

View full abstract page.

  • Shankar Vemulapalli, Cisco Systems
  • Shankar Vemulapalli is a Technical Lead in the Internet Service Provider Support Group at Cisco, involved in designing large-scale ISP networks with an emphasis on IS-IS. His other areas of interest include OSPF, EIGRP, MPLS-TE, and MPLS-VPNs. Vemulapalli has written several IS-IS documents for the Cisco web site, and has also served as a CCIE Lab Proctor.
pptIS-IS Deployment(PPT)
youtubeIS-IS Deployment & Design Guidelines, with Emphasis on New Features
3:00pm - 3:30pm Break
3:30pm - 5:00pmSandringham Room

Tutorial: Deploying IP Multicast

This session takes a detailed look at the protocols required for deploying IP multicast in a provider network, and how the protocols fit together. Also included is a breakdown of the how-and-why of IP multicast and the driving business models for deployment.

View full abstract page.

  • Greg Shepherd, Juniper
  • Greg is a Consulting Engineer for Juniper Networks, focusing primarily on multicast protocols, performance, customer solutions, and market drivers. Before joining Juniper, Greg worked in multicast development at Cisco Systems, spending most of his time in customer deployment, and also presented the Advanced Multicast Routing tutorial for Cisco Networkers. Until recently he held a faculty position at the University of Oregon\'s Advanced Networking Technology Center, where he provided multicast direction to the Internet2 community. Greg also sits on the Board of Advisors for Digital Fountain.
3:30pm - 5:00pmChopin Ballroom

Tutorial: Routing Policy Implementation Guide

This tutorial will cover the important decisions that network operators and designers must make when building or expanding IP networks. The primary focus will be on routing policy, including: <UL> <LI> Prefix length filtering</LI> <LI> Implementation of robust BGP communities</LI> <LI> Methods of controlling route advertisement to peers, customers, and transit providers. <BR><BR></LI> </UL> Particular attention will be given to considerations for networks planning to explore or expand peering strategies. <BR><BR> Level: intermediate <BR><BR> The intended audience is network engineers from large enterprises or small- to medium-sized carriers and ISPs. A basic knowledge of BGP and IP routing protocols is strongly suggested.

View full abstract page.
  • Dan Golding, Sockeye.
pptDaniel Golding Presentation(PPT)
youtubeRouting Policy Implementation Guide
Monday, February 11 2002
Time/Webcast:Room:Topic/Abstract:Presenter/Sponsor:Presentation Files:
9:00am - 9:15amGrand BallroomWelcome, IntroductionsSpeakers:

  • Monty Bannerman, Terremark
  • Monty Bannerman is responsible for all technical operations at Terremark Worldwide, Inc., and participates in corporate strategic planning. He has more than 20 years of telecommunications experience that encompasses management, sales, operations and domestic and international business development. Monty founded IXS.NET, a provider of IP telephony services in China, and DSP.NET, an ISP in the Bay Area. Prior to founding these companies, he was Vice President of Bell Canada International (BCI), where he was responsible for international investments and the implementation and operations of advanced voice and data networks for carriers, governments and corporations.
  • Susan Harris, Merit Network.
pptMonty Bannerman Presentation(PPT)
youtubeWelcome, Introductions
9:15am - 10:15amGrand Ballroom

Network and Node Availability Improvements through Routing Protocol and Signaling Extensions

There have been many recent extensions to the routing and signalling protocols to increase network and node availability. These extensions are different for the IGPs, BGP, multicast, and MPLS signalling protocols because unicast, multicast and MPLS all have different network characteristics.<BR> <BR> This presentation will give an overview of the extentions and describe what will be observed by network operators and their customers. Also, there will be a description of the tradeoffs between choosing a protection/restoration approach at different layers of the network and practical deployment considerations.

View full abstract page.
  • Dave Ward, Cisco Systems.
pdfDave Ward Presentation(PDF)
youtubeNetwork and Node Availability Improvements through Routing Protocol and Signaling Extensions
10:15am - 10:45amGrand Ballroom

How to Secure Your Job: Implement MPLS VPNs

Back in Q3 1999, Nextra (Switzerland) deployed a nationwide MPLS VPN service. In Q1 2001, this service was extended to all european Nextra companies (which have their own ASNs) in order to provide a seamless, pan-european MPLS VPN service.<BR> <BR> This presentation will discuss some of the ideas behind the service architecture. There will also be a discussion about lessons learned when implementing and running a real-life MPLS VPN network.

View full abstract page.

  • Roger Gottsponer, Nextra
  • n 1999, Roger Gottsponer joined Nextra (Switzerland) as a senior network engineer, where he became heavily involved in the design and planning of the MPLS VPN service. Previously, Roger worked as a network engineer at SWITCH, the Swiss Academic and Research Network, where he has been involved with all aspects of IP routing.
youtubeHow to Secure Your Job: Implement MPLS VPNs
pptRoger Gottsponer Presentation(PPT)
10:45am - 11:00amGrand BallroomBreak
11:00am - 11:45amGrand Ballroom

Global Crossing\'s Operational Experience With MPLS

Global Crossing deployed MPLS in Q2 1999 to solve a variety of issues we faced while integrating various purchased networks, and migrating them to Frontier\'s fiber optic backbone. We built upon that foundation to later provide true MPLS-enabled VPNs. The presentation objectively reviews our experiences with MPLS, what it enables us to do, and the advantages it provides for us. I will do my best not to stray into the subjective, as I don\'t want to start a religous discussion about MPLS :) An outline of the talk follows: <UL> <LI> Overview of architecture <UL> <LI> Physical</LI> <LI> Logical</LI> </UL> </LI> <LI> History of network</LI> <LI> Early challenges and how MPLS solved them</LI> <LI> Challenges with MPLS today <UL> <LI> Multi-vendor core</LI> <LI> Advanced features such as fast-reroute, secondary LSP\'s, etc. </LI> </UL> </LI> <LI> How the network would behave without MPLS</LI> <LI> VPN deployment <UL> <LI> Architecture</LI> <LI> Capabilities (2547, l2vpn)</LI> <LI> Provisioning aspects</LI> <LI> Customer experiences</LI> </UL> </LI> <LI> IPv6 deployment w/ MPLS</LI> </UL>

View full abstract page.

  • Dave Siegel, Global Crossing
  • Dave Siegel has been involved with Internet network engineering since 1992, and joined the NANOG community in February 1995. He has been with Global Crossing since April 1998 in various roles, with a primary focus in IP network architecture, design, and implementation. He is presently the IP Engineering Director, and is reponsible for all engineering aspects of the IP backbone, including architecture, design, implementation, capital spending, planning, traffic engineering, router configuration standards and routing, peering, OSS development and deployment, and supporting systems platforms.
pptDave Siegel Presentation(PPT)
youtubeGlobal Crossing's Operational Experience With MPLS
11:45am - 12:05pmGrand Ballroom

An Approach to IP Network Traffic Engineering

Cable & Wireless (AS 3561) implements a strict traffic engineering network underlying its IP transit networks. This network has existed in some form or other for the last six years, and has provided C&W a high level of determinstic behavior and stability. This presentation will cover the major elements of that traffic engineering architecture, as well as some of the considerations and trade-offs made in the implimentation of the architecture.

View full abstract page.

  • Chris Liljenstolpe, Cable & Wireless
  • Chris Liljenstolpe is the Sr. Director and Chief Scientist for Network Technologies at Cable & Wireless. He has been invloved with the packet network architecture at C&W for the last three years, including the traffic engineering component.
youtubeAn Approach to IP Network Traffic Engineering
pptChris Liljenstolpe Presentation(PPT)
12:05pm - 1:30pm Lunch
1:30pm - 2:00pmGrand Ballroom

New Directions in Peering for Tier-2 and Content Providers

The past two years have seen explosive growth in peering between Tier-2 ISPs, content providers, and others. This new and powerful trend in peering has caused a great deal of innovation and cost reduction, as companies such as PAIX, Equinix, and other collocation providers adjust to the new market. Recently, however, there have been three events which are proving disruptive to the peering industry: <OL> <LI> The rapid drop in the price of transit around and following the collapse of many Internet businesses a year ago. <BR><BR></LI> <LI> The decision of the top seven Tier-1 Service Providers to seek common collocation space for \"Next-Generation\" peering at OC-48 and higher speeds. <BR><BR></LI> <LI> The availability of Metropolitan Multipoint Private Peering services on Metro-Ethernet, enabling efficient private peering as well as multipoint peering VLAN services similar to an exchange point, but distributed to multiple POPs in a metro area. <BR><BR></LI> </OL> This presentation first gives an historical viewpoint on the economic motivations of peering, and then examines the impact of these three disruptions on the direction of peering in the industry. In particular: <OL> <LI> The new low prices for transit service mean that traditional Peering methods, such as legacy NAPs and private line peering, no longer offer the financial advantage over transit that they once did. Providers of peering services must provide a lower cost point in order to retain their business. <BR><BR></LI> <LI> There is much Fear, Uncertainty, and Doubt clouding the issue of the large Tier-1s moving into common facilities for peering. The speaker presents an outsider\'s view on this move and its likely impact on peering, as well as on the collocation and transit markets. <BR><BR></LI> <LI> Metro-Ethernet, with its inherent VLAN and multipoint capabiltiies, provides a new means of private peering in major Internet markets, with a price point that can significantly improve on traditional private lines if engineered correctly. Several Metro-Ether providers have signalled their intention to offer peering-centric services centered around these capabilities; the speaker will discuss the likely impact on the peering industry of such services. <BR><BR></LI> </OL> Recent and likely future trends in peering are discussed throughout, including prices and levels of savings. Finally, relevant companies and their services are briefly discussed (from an outsider\'s view, with permission) and points of contact made available to those interested in examining the new services.

View full abstract page.

  • Jeb Linton, EarthLink
  • Jeb Linton\'s background is in Network and Communications Systems Engineering research, development, and consulting for the Defense and Intelligence communities. He was hired during the merger of EarthLink, Mindspring, and OneMain to help integrate its legacy networks with a new backbone architecture. He has spent the past year developing a peering strategy for EarthLink while working with major Tier-1, collocation, and Metro-Ethernet providers on their peering strategies and service offerings.
pptJeb Linton Presentation(PPT)
youtubeNew Directions in Peering for Tier-2 and Content Providers
2:00pm - 3:00pmGrand Ballroom

Panel: Updates From the NAPs

There has been continued growth and change in the North American NAP scene in the last two years, including new players and new exchange technology, with the mid/late-90\'s ATM fabrics being left behind for public exchange based on Gigabit Ethernet, and now some ventures using MPLS. Some exchanges are conducting experiments with multicast and IPv6 peering. There have also been some interconnections of different L2 exchanges, bringing a new set of challenges.<BR> <BR> This presentation and discussion topic will be split into two sessions. The general session will comprise brief (~5 minute) updates from a handful of exchanges who have new technology developments or progress to report, followed by time for a short panel discussion between the audience and the operators.<BR> <BR> Monday evening, a BOF session will provide an \"Open House\" for exchange operators who were not able to speak during the main session to introduce themselves and say a few words about what they are doing. Also, there will be an opportunity for more detailed discussion of any items that \"overflow\" from the general session.<BR> <BR> Finally, it\'s also a great opportunity to meet up with the people who operate the exchanges where you participate, or talk to a new exchange that you are considering expanding to. We will probably ajourn to the bar soon!

View full abstract page.

  • Mike Hughes, LINX
  • Mike Hughes has over five years of experience in the industry. He currently holds the position of Network Architect for the London Internet Exchange (LINX), where he has worked for the last three years. LINX is one of the key exchanges in Europe, and handles over 13 Gigabits per second of peering traffic over a gigabit ethernet infrastructure. As an early adopter of new technologies, Mike is behind a pioneering installation of 10 gigabit ethernet in an exchange environment.<BR> <BR> Previous to working at LINX, he held various network and engineering roles at the UK-based ISP Direct Connection (now known as Netscalibur UK). He holds a B.Sc. (Hons.) degree in Transport Management from Aston University, Birmingham, where he first got hands-on experience with the Internet via the University\'s VAX/VMS systems.
  • Tom Bechly, MAE Services.
  • Matthew Brooks, NOTA.
  • Albert Crews, Bellsouth MIX.
  • Avi Freedman, MetroIX.
  • Tony Haeuser, SBC NAPs (AADS, PacBell).
  • Jeff Meltzer, MetroIX.
  • Lane Patterson, Equinix.
  • Akio Sugeno, NYIIX/LAIIX/6IIX.
  • Paul Vixie, PAIX.
pptBechly Presentation(PPT)
pptHaeuser Presentation(PPT)
pptHughes Presentation(PPT)
pptMetroIX Presentation(PPT)
youtubePanel: Updates From the NAPs
pptPatterson Presentation(PPT)
pptSugeno Presentation(PPT)
3:00pm - 3:30pmGrand Ballroom

.com/net/org Registry Update

This presentation describes recent and planned changes at the .com/.net/.org registry that will interest network operators. Topics include: <UL> <LI> The long-standing requirement that IP addresses of name servers (i.e., A records) be unique will soon be lifted. It will then be possible to register two different name servers with the same IP address. <BR><BR></LI> <LI> The .com, .net and .org zones include many unnecessary A records, such as A records not referenced by any NS records. These \"orphan\" A records will soon be removed. <BR><BR></LI> <LI> Upcoming support for registration and resolution of AAAA records for IPv6. <BR><BR></LI> <LI> Registration and resolution volume metrics. <BR><BR></LI> </UL>

View full abstract page.
  • Matt Larson, VeriSign.
youtube.com/net/org Registry Update
pptMatt Larson Presentation(PPT)
3:30pm - 3:45pm Break
3:45pm - 4:15pmGrand Ballroom

DNS Damage: Measurements at a Root Server

The root of the DNS distributed database is managed by 13 root nameservers. We passively measure the performance of one of them: F.root-servers.net. These measurements show an astounding number of bogus queries: from 60-85% of observed queries were repeated from the same host within the measurement interval. Over 14% of a root server\'s query load is due to queries that violate the DNS specification. Denial of service attacks using root servers are common and occurred throughout our measurement period (7-24 Jan 2001). Though not targeted at the root servers, DOS attacks often use root servers as reflectors toward a victim network. We contrast our observations with those found in an earlier study of DNS rootserver performance by Danzig et. al. <BR><BR> <A HREF=\"http://www.caida.org/publications/presentations/ietf0112/dns.damage.html\" TARGET=\"_BLANK\">Presentation Slides</A>

View full abstract page.

  • Evi Nemeth, CAIDA
  • Evi Nemeth was a member of the Computer Science faculty at the University of Colorado, a visiting professor at UC San Diego, and a CAIDA researcher. Evi still dabbles in CAIDA projects as she tries to retire from the world of computers and networks to see the real world on her 40\' sailboat.
youtubeDNS Damage: Measurements at a Root Server
4:15pm - 5:00pmGrand Ballroom

Internet Measurement: Myths About Internet Data

Current papers that propose new techniques and protocols often make assumptions about traffic characteristics that are simply not validated by real data. Hypotheses about the level of fragmented traffic, encrypted traffic, topology characteristics, traffic favoritism, path symmetry, DOS attack prevalence, address space utilization and consumption, directional balance of traffic volume, routing protocol behavior and policy, and distribution statistics of path lengths, flow sizes, packet sizes, prefix lengths, and routing announcements therefore yield questionable analytical results. Even in cases where analysis is based on data attainable by a researcher on his or her local campus, attempts to generalize typically lose integrity in the face of more complete or representative data sets. <BR><BR> This talk will show several examples of measurements that shed doubt on commonly assumed Internet myths. The implication is that the community could make much better use of its collective intellectual resources if we could validate ideas against a larger variety of empirical data sets before investing research and development time and energy on certain studies. <BR><BR> You\'ll also see pretty pictures of network data stuff, as always. <BR><BR> <A HREF=\"http://www.caida.org/publications/presentations/Myths2002/\" TARGET=\"_BLANK\">Presentation slides</A>

View full abstract page.
  • K Claffy, CAIDA.
youtubeInternet Measurement: Myths About Internet Data
5:30pm - 7:30pmBayfront RoomBeer n Gear
  • Sponsors Avici Systems; Cisco Systems; Extreme Networks; Force10 Networks; Foundry Networks; Gotham Networks; OPNET Technologies; Pluris; Redback Networks.
  • Sponsors
  • 7:30pm - 9:00pmChopin BallroomNAP Update, Part II: Meet the OperatorsModerators:
    • Mike Hughes, LINX.
    7:30pm - 9:00pmTrade Room


    This BOF gives the community an opportunity to provide input to VeriSign concerning requirements for its universal whois project (UWho). UWho, a non-centralized, administrative lookup service, is intended as a non-proprietary, open standard. Presently, VeriSign is seeking input for requirements and has presented two straw-proposals: one based on XML and the other based on LDAP (see the NANOG 23 UWho presentation for more information.) <BR><BR> The interactive session will include: <UL> <LI> VeriSign presentation on requirements gathered so far. <BR><BR></LI> <LI> Presentations from other operators (ccTLD, regional routing registries, etc). <BR><BR></LI> <LI> Most importantly, presentations and open mike from network operators about what they would like to see in an administrative lookup service. <BR><BR></LI> </UL>

    View full abstract page.
    • Leslie Daigle, VeriSign.
    • Andrew Newton, VeriSign.
    pptAndrew Newton Presentation(PPT)
    pptCathy Murphy Presentation(PPT)
    9:00pm - 10:30pmTrade Room

    Route Registry

    This BOF will provide an opportunity for updates on the RADB and exchange of information among the route registries. Please join us! <BR><BR> A tentative agenda follows: <UL> <LI> Introductions - Larry Blunk, Merit</LI> <LI>IRRd software updates</LI> <LI>RADB issues - Consistency, Maintainer Reports</LI> <LI>RPSL issues - RPSLng (IPv6/Multicast), Authorization security</LI> <LI>New RADB billing process and clean-up - Chris Frazier, Merit</LI> <LI>Merit summation - Jeff Ogden, Merit Comments/Discussion</LI> <LI>APNIC IRR update - Terry Manderson, APNIC </LI> </UL>

    View full abstract page.
    • Larry Blunk, Merit Network.
    10:30pm - 11:00pmTrade RoomPGP Key Signing
    Tuesday, February 12 2002
    Time/Webcast:Room:Topic/Abstract:Presenter/Sponsor:Presentation Files:
    9:00am - 9:30amGrand Ballroom

    ISIS Routing on the Qwest Backbone: a Recipe for Subsecond ISIS Convergence

    Routing \"convergence\" time, or the delay to reroute, is often cited as one of the key limitations for currently deployed IP networks to provide new services and scale to larger sizes. In this talk, we present an analysis of ISIS routing protocol behavior in one ISP network to demonstrate where the problems lie and how to fix them. This analysis is based on ISIS packet traces collected over multiple week-long periods on several major ISP backbone networks. The analysis focuses on two aspects.<BR> <BR> First, by observing the number of link-state packets generated and analyzing how many represent real physical changes, we show that only a few routers and links are responsible for the majority of the churn. Some of the links, when they fail, become unstable and cause continuous churn.<BR> <BR> Second, we analyze in detail the sequence of events and delays that result in convergence taking multiple seconds. We correlate the routing state learned from tracing ISIS routing packets with observations of the effects of routing upon a continuous stream of UDP test traffic while the convergence progresses. This allows us to detect link failures very quickly and to see precisely when the route changes.<BR> <BR> We have observed that during a single convergence event our stream was first black-holed, then sub-optimally routed, then looped, and finally converged to the new, optimum route. All of these steps took several seconds due to link failure detection times, link-state packet propagation times, and the surprising effect of some of the ISIS timers. By combining fixes for these problems with the results of our earlier lab experiments (as reported at NANOG 20), we conclude with a recipe for achieving subsecond IGP convergence in networks such as this ISP\'s all point-to-point core network.

    View full abstract page.

    • Cengiz Alaettinoglu, Packet Design
    • Cengiz Alaettinoglu ([email protected]) is a member of the Technical Staff at Packet Design. He is currently working on scaling and convergence properties of both inter-domain and intra-domain routing protocols. He was previously at the USC Information Sciences Institute, where he worked on the Routing Arbiter project. Cengiz co-defined the Routing Policy Specification Language along with the protocols to enable a distributed, secure routing policy system.

    • Steve Casner, Packet Design
    • Stephen Casner worked on packet audio and video for 27 years, going from the ARPAnet through the MBone. This was first in the academic setting at USC/ISI, then going commercial at Precept Software and Cisco Systems. Now he is applying some of the same techniques for network performance measurement at Packet Design.
    pdfCengiz Alaettinoglu Presentation(PDF)
    youtubeISIS Routing on the Qwest Backbone: a Recipe for Subsecond ISIS Convergence
    9:30am - 10:00amGrand Ballroom

    Identifying Problematic Inter-domain Routing Issues

    Even today, with the widespread usage and critical importance of the Internet, basic routing protocols such as BGP are poorly understood. The important gaps in our understanding include: what causes BGP instability; what is the influence of policy changes on BGP instability; the impact of multi-homing with its blackholes in the routing hierarchy; BGP convergence rate; and the interaction of EBGP, IBGP, and other intra-domain routing protocols.<BR> <BR> These are just a few of the questions. To be able to solve problems and/or answer the questions above, we first need to characterize the routing tables and routing updates and determine how their variability relates to the structure of the Internet. In this talk we first discuss the public domain tool \"character,\" which identifies and categorizes BGP routing updates in the context of related updates, and we then present some preliminary analysis results.<BR> <BR> Character consists of two parts (implemented as Perl modules): a low-level module, \"FileFinder.pm,\" which provides an intermediate layer between raw BGP data collected via tools such as mrtd, gated, etc.; and the analysis module \"Check.pm,\" which includes functions for the identification and characterization of routing updates. Check provides a extensible and flexible interface for categorizing and analyzing BGP routing updates.<BR> <BR> Character\'s input data includes two BGP tables and all BGP updates in between. The two table dumps are used as reference points and for identifying missing updates. (We realize that table dumps aren\'t perfect. But the analysis of many such tables and updates allows us to identify characteristics rather then spurious artifacts.)<BR> <BR> Character\'s main data structure is organized by prefix and contains each update:prefix plus attributes. This data structure allows character to identify whether a specific update is a new one (in the considered time frame) or if it has been processed before (using Craig Labovitz\'s terminology is it an AA-DIFF, an AA-DUP, an AW-DIFF or a WA-DIFF); if the attributes of the update have changed and in which way, e.g., at which AS the AS-path has changed and where it is rejoining in the old way.<BR> <BR> Besides keeping per-prefix information, character also computes per-AS information, such as the percentage of currently seen updates (near in time) which came through an AS. In addition, it calculates the percentage of total routes through each AS vs. the maximal number of prefixes associated with the AS.<BR> <BR> One of the more interesting questions is whether a prefix is flapping. Character keeps track of the overall number of flapping prefixes as well as the number of flapping prefixes originated by the last AS on the AS-path. Besides flapping, character also allows us to study re-convergence. Here re-convergence means: a failure somewhere results in a withdrawl of a route, an alternative route is announced, and after the repair of the failure, the original best route is reannounced, resulting in a flap with two different updates in between.<BR> <BR> An old suspicion is that a significant portion of routing table updates is the result of BGP session resets. Each reset causes the two participating peers to exchange their full routing table and redistribute the learned information to their peers. Therefore the effects of routing table resets are visible even if the responsible peers are many AS-hops away. To identify these session resets character keeps track of how many updates are being processed by the router each time a new update arrives. From this character can compute the total number of updates per time period and the number of prefixes with updates per time period. In addition, character computes the same information for every AS: total number of updates (number of prefixes with updates) per time period involving this AS. If a rate exceeds some predefined rate, this update is marked as part of a peak (a possible session reset).<BR> <BR> We applied character on BGP table data from RIPE\'s \"rrc00\" peering point during Christmas 2001, and found that less than half of the updates during a period of a day are really \"new\" or \"unique\" ones - all other updates have been seen before (with exactly the same attributes). What has changed between the last update and this one?<BR> <BR> Using Craig Labovitz\'s terminology, over 60% of the updates can be categorized as AA-DIFF, 15% AA-DUP (most of them correlate with session resets), 11% AW-DIFF, and 7% WA-DIFF. There are only a few withdraws - most of the updates are route replacements. With regards to attribute changes, we find that 22.0% involve only changes in the AS on the AS-path but no change in the AS-path length; in 14.5% the AS-path is getting longer (not due to policy changes); in 13.8% the Community field has changed; and in 12.9% the AS-path is getting shorter. Other updates involve policy changes, in which the AS-path is getting longer because of a community change, or the other way around.<BR> <BR> Most of the time the AS-path changes somehow. Therefore we next investigate whether it reestablishes its connectivity according to the old path. We find that it is the originating AS in 41%, a transit AS in 53% and that the originating AS has changed in roughly 6% of the cases.<BR> <BR> With regards to route flapping, we find that even in times of route flap dampening nearly half of all updates are still flapping prefixes (one third of the updates are flapping from time to time - and 14% of all seen prefixes are ONLY flapping prefixes; all flaps have a mean around 51 minutes between flaps). If a prefix is flapping, in over 50% percent of the cases all other prefixes announced by the last AS in the AS-path are flapping as well.<BR> <BR> We observed classical re-convergence, but less than 14% of the routes that flap with two updates in-between fall into this category. We note that during certain time periods a single AS is responsible for almost all of the updates, and more than one third of all updates are due to session resets. Indeed session resets cause large peaks (with over 2000 updates per second!) which have to be processed by the router\'s processor.<BR> <BR> The described functions answer some questions about what is happening - but they don\'t answer questions about how to avoid these problems in the future. Therefore our next step will be to put together all necessary tools needed to construct a testbed with realistic routing tables and updates. With its help we expect to answer some of the questions related to Internet scalability.

    View full abstract page.
    • Anja Feldmann, Saarland University, Saarbruecken, Germany.
    • Olaf Maennel, Saarland University, Saarbruecken, Germa.
    youtubeIdentifying Problematic Inter-domain Routing Issues
    pptOlaf Maennel Presentation(PPT)
    10:00am - 10:30amGrand Ballroom

    Internet Expansion, Refinement, and Churn

    We analyze the evolution of the global Internet interdomain routing system on AS, prefix and IP address level granularities, using snapshots of RouteViews BGP tables from 1997 to 2001. We introduce the notion of semiglobally routed prefixes, i.e., those present in the majority of backbone tables, and classify them into: <UL> <LI> Standalone -- those which have no subsets, no supersets <BR><BR></LI> <LI> Root -- have subsets, but no supersets <BR><BR></LI> <LI> Subset -- more specific, which are subsets of other blocks. Using these distinctions we find that from 1999 to 2001 many measures of routing system complexity demonstrated stability in the form of slow growth, dynamic equilibrium, and occasional contraction. <BR><BR></LI> </UL> We find that many net change measures reflect contributions of the opposite sign, and that true measures of variation, or churn, should take into account absolute magnitudes rather than their difference. Appearance and disappearance of prefixes, ASes and RouteViews peers, as well as status changes (an AS changing from transit to non-transit, or a prefix shifting from a standalone prefix to a root prefix) are instances of routing system churn. We find that the rates of long-term appearance and disappearance for IP addresses, prefixes, and ASes have comparable magnitudes and what is viewed as growth is sometimes just the \"tip of the iceberg,\" with two rates almost cancelling each other out. <BR><BR> One advantage of using our notion of semiglobal prefixes is that they exhibit less churn than global prefixes (those prefixes common to all backbone tables) and as such allow for derivation of more robust macroscopic statistics about the routing system. <BR><BR> We study route prefix instability at a medium time granularity for late 2001 using 2-hour snapshots of BGP tables, and find that half of all prefix reannouncements (flips) are contributed by 1% of all ASes, with government networks, telecoms in developing countries, and major backbone ISPs at the top of the list of instability contributors. Small ASes (those that originate only a few prefixes into the global routing system) do not contribute more than their fair share of either route entries or churn. We conclude that during 1999-2001 many Internet metrics were stable, even though the sets that they measure were changing rapidly, and that the routing system\'s growth and instability are mostly caused by large and medium-sized ISPs. <BR><BR> See below for presentation slides: <BR><BR> <A HREF=\"http://www.caida.org/~broido/nanog200202.egr.pdf\">http://www.caida.org/~broido/nanog200202.egr.pdf</A>

    View full abstract page.
    • Andre Broido, CAIDA.
    • K Claffy, CAIDA/UC San Diego.
    • Evi Nemeth, CAIDA/UC San Diego.
    youtubeInternet Expansion, Refinement, and Churn
    10:30am - 10:45am Break
    10:45am - 11:30amGrand Ballroom

    Inter-domain Multicast in European Research Networking: TEN-155 Operational Experience and Deployment of GEANT

    This presentation will highlight the development and experience gained during the introduction of native inter-domain multicast in the European research community on the TEN-155 network, as well as the decisions made for its successor network, GEANT.<BR> <BR> The first part of the presentation will cover the process of migrating from the previous MBone to an infrastructure based on PIM-SM and MBGP/MSDP. This provided a multicast service to 18 European countries with interconnections to commercial ISPs (e.g., AUCS-Infonet, UUNET) and to the US research network Abilene. The presentation will outline operational experience and results gained from mechanisms put in place to monitor multicast traffic.<BR> <BR> The second section of the talk will concentrate on the deployment of GEANT, the successor to TEN-155, which is a 10 Gbit/s pan-European network. It will carry multicast traffic for 28 countries in Europe by February 2002, and will be interconnected with several US and Canadian research networks (Abilene, Esnet, Canarie) plus commercial ISPs. The presentation will focus on the technical choices made for the design of multicast, and plans for offering multicast as a fully supported service from an operational perspective. In this context, the authors will present the first results obtained from monitoring the core backbone and customers with an enhanced version of the public domain tool Beacon.

    View full abstract page.
    • Jan Novak, Cisco Systems.
    • Agnes Pouele, DANTE.
    pptAgnes Pouele Presentation(PPT)
    youtubeInter-domain Multicast in European Research Networking: TEN-155 Operational Experience and Deployment of GEANT
    11:30am - 12:00pmGrand Ballroom

    Pseudowires and L2TPv3 Engineering

    Emulation of various layer 2 link types (\"pseudo-wires\") over IP presents an interesting and potentially valuable choice for service providers looking to consolidate disparate networks or provide new services over a common infrastructure. The Layer Two Tunneling Protocol (L2TP), defined by the IETF, provides a necessary basis for tunneling capabilities used in \"pseudo-wire\" emulation over IP. First used for emulation of PPP data links over IP. L2TP is being adopted for a number of new data link services, including Frame Relay, ATM, Ethernet, and others.<BR> <BR> This discussion will provide a technical overview of L2TPv3, as well as a peek into how it is currently being utilized for pseudo-wire services. A brief overview of the PWE3 (pseudo-wire edge to edge) activity in the IETF will also be presented.

    View full abstract page.
    • Gilles Deworm, Ebone.
    • Mark Townsley, Cisco Systems.
    pptGilles Deworm Presentation(PPT)
    pptMark Townsley Presentation(PPT)
    youtubePseudowires and L2TPv3 Engineering
    12:00pm - 1:30pm Lunch
    1:30pm - 1:45pmGrand BallroomOperator Requirements for Infrastructure ManagementSpeakers:
    • Steve Feldman, Vivace.
    youtubeOperator Requirements for Infrastructure Management
    pptSteve Feldman Presentation(PPT)
    1:45pm - 2:30pmGrand Ballroom

    NOC Theory and Practice

    Network operations centers are not equal - some do it better than others, some do it far better than others, and some just do it. What are the elements that go into an effective, productive, and well-oiled NOC? In addition, what are the essential components a NOC, regardless of scale? What are the concerns on your mind when managing or building your NOC? Are your people happy, is your security good, are your procedures solid? Is there a good framework for evaluating NOC performance? <BR><BR> This talk will cover the following topics: <BR><BR> I. NOC Theory (Matt Ringel) <UL> <LI> Introduction: definition of NOC as it applies to this presentation</LI> <LI>Theory <UL> <LI> Overview - what a NOC should do, as related to organizational needs</LI> <LI> Methodology for dividing operations</LI> <LI> Inputs and outputs of a NOC: what a NOC \"receives\" (events, calls, maintenance requests, etc)</LI> <LI> What a NOC \"provides\" (status updates, resolutions, status information) <BR><BR></LI> </UL> </LI> <LI> Scaling and Portability <UL> <LI> Bare-bones NOC vs. NORAD-style NOC: compare and contrast</LI> <LI> Modularity and the concept of a \"portable NOC\"</LI> <LI> Disaster recovery and the portable NOC</LI> <LI> \"Carving out\" a portable NOC</LI> <BR><BR></LI> </UL> </LI> </UL> II. NOC Practice (Timothy Brown) <UL> <LI> Introduction: what is in a good NOC?</LI> <LI> Physical concerns - security, location, ergonomics</LI> <LI> What to do if you are rebuilding (or building) your NOC</LI> <LI> People concerns - retention, care and feeding/happiness, productivity</LI> <LI> Policies and procedures: how work should be streamlined within your NOC (focus on backbone NOCs) <BR><BR></LI> </UL> III. Joint presentation - Evaluating your NOC (Tim and Matt) <UL> <LI> Criteria for evaluation - what matters</LI> <LI> The customer\'s perspective</LI> <LI> What you should never say to a customer</LI> <LI> What you should promise to a customer - ETR</LI> <LI> Example evaluation </LI> </UL>

    View full abstract page.
    • Timothy Brown, Akamai Technologies.
    • Matthew F. Ringel, Akamai Technologies.
    pptBrown Presentation(PPT)
    youtubeNOC Theory and Practice
    pptRingel Presentation(PPT)
    2:30pm - 3:00pmGrand Ballroom

    Real-world Techniques for Automating the Configuration of Network Devices

    In this talk, the presenter will discuss real-world experience garnered doing automated configuration of network devices in the field using Tcl and Expect. What were the challenges? What was learned about exception handling and reliability? What are some strange discoveries made about common devices? <BR><BR> An outline follows: <BR><BR> I. Issues surrounding move, add and change control for network devices <UL> <LI> Complexity from having multiple devices</LI> <LI> Complexity from having a large, highly distributed network--how to update firmware, etc. for remote devices</LI> <LI> Need for reliability</LI> <LI> Need for automation</LI> <BR><BR></LI> </UL> II. Need for Network Integrity <UL> <LI> Detection of drift</LI> <LI> Archiving <BR><BR></LI> </UL> III. Description of an architecture for automated network device control. Based on work done in conjunction with several large organizations managing global networks. <BR><BR> IV. Automated device manipulation techniques using Tcl and Expect <UL> <LI> Description of a large global financial services firm\'s experience with device control automation, problems that arose, and how they were handled. <BR><BR></LI> <LI> Specific examples (with Tcl/Expect code on screen): <BR><BR> <UL> <LI> The problem of prompts; buffer skew, false positives and how to deal with the problem in Tcl code</LI> <LI> Speed of entry</LI> <LI> Use of terminal servers and real (not virtual) consoles</LI> <LI> Firmware revision annoyances</LI> <LI> Control channel networking problems</LI> <LI> Parse-ability of configurations</LI> <LI> Differential configuration </LI></UL> </LI></UL>

    View full abstract page.

    • Mark Epstein, Ponte
    • Mark Epstein has 14 years of experience in the security and network administration fields, having held leadership positions at organizations such as McAfee and Silicon Graphics. While at Silicon Graphics, Epstein led the team that created OpenVault (TM), a distributed storage resource broker that enables any storage management application to interface with robotic storage libraries, regardless of vendor. Epstein drove the OpenVault technology to become an IEEE standard.<BR> <BR> Prior to working at Silicon Graphics, Epstein headed the team that created the X-terminal multi-platform installer for Network Computing Devices (NCD), which enabled NCD\'s X-terminal products to be used with more than a dozen Unix platforms. The code eliminated a formerly arduous manual process by automating the creation of the host-side objects that enabled the X-terminals to function properly.<BR> <BR> In addition, he has front-line Network Operations Center (NOC) experience from his tenure at UC Berkeley Central Computing Services, where his duties included resource control, security, and network and systems administration for much of the campus.
    pptMark Epstein Presentation(PPT)
    youtubeReal-world Techniques for Automating the Configuration of Network Devices
    3:00pm - 3:15pmGrand BallroomClosing RemarksSpeakers:
    • Susan Harris, Merit Network.
    youtubeClosing Remarks


    ^ Back to Top