Agenda

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>

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.

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.

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.

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.

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>

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>

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>

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.

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.

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>