NANOG 18 Agenda

This tutorial explains how MPLS is being used to engineer traffic flows inside ISP networks. We present the entire set of components that are used in the traffic engineering architecture. We then demonstrate the exact function of each component. A number of examples compare how each component helps improve the current destination-based forwarding network model, i.e., traffic engineering benefits over traditional layer 2 networks.<BR> <BR> Finally, new features for traffic engineering are described and practical network deployment scenarios examples are presented.

This presentation looks at the high-level evolution of our network infrastructure and ponders the direction that we are going. These issues have an important impact on network operators\' short-to-medium-term planning and investments. An outline of the talk follows: <UL> <LI> History (and reasoning) <UL> <LI> TDM Circuits</LI> <LI> VCs/TDM Circuits</LI> <LI> Optical Circuits</LI> <LI> MPLS/Optical Circuits </LI></UL> </LI> <LI> Protocols <UL> <LI> HDLC</LI> <LI> FR</LI> <LI> ATM</LI> <LI> MPLS</LI> </UL> </LI> <LI> Convergence <UL> <LI> Evolving Optical Routing</LI> <LI> Ubiquity of IP Applications <UL> <LI> MIT\'s Project Oxygen</LI> <LI> Wireless Access</LI> </UL> </LI> </UL> </LI> <LI> Future Likelihoods <UL> <LI> Shared Infrastructure</LI> <LI> Distributed Computing as a driver <UL> <LI> Akamai</LI> <LI> caching</LI> <LI> \'bots\' and silicon cockroaches </LI></UL> </LI></UL> </LI> </UL>

Broadband services, such as DSL, are now being rolled out by multiple telcos in Tier 2-4 markets. Traditionally, these markets have not been stopping-points for the major backbone providers (Sprint, UUNET, iMCI, CW, et al.) and as such don\'t have high speed transit connections (DS3 and above). In addition, these locations do not have good local peering meet points, or IX\'s, for local or regional traffic. <BR><BR> Currently, the major peering points are the MAE\'s and PAIX. Most large providers will only peer with a local/rural ISP if they can make it to these locations. However, the distances, and thus the mileage-based cost for circuits to these locations, are extremely expensive. For example, a DS3 from ABQ to PAIX will cost between \$20,000 to \$45,000 per month, and that is just the circuit cost. One still has to obtain space and a router at PAIX. <BR><BR> Major backbone providers currently do not see a need to put large POPs in these Tier 2-4 cities. They cite the \"lack of demand\" for services which, one could say, is a myopic point of view. DSL is exploding in these markets and the demand is there now. The transit links are not. <BR><BR> If an ISP wanted to get a DS3 to UU.NET (even Frac DS3) it would have to pay backhaul to PHX or LAX or DFW. This increases the cost of the transit beyond what most local ISP\'s can afford. <BR><BR> If broadband services are going to be sucessful in these markets, the local ISP needs to have better access to better networking. <BR><BR> In other words, we would like to encourage: <UL> <LI> The promotion and education of local IX\'s.</LI> <LI> The creation of local IX\'s.</LI> <LI> Better access to backbone transit vendors without the backhaul costs.</LI> <LI> Regional and national backbone vendors exchanging routes at locations other than the current MAE\'s/PAIX\'s.</LI> <LI> The willingness to peer at local IX\'s, and not just local routes <BR><BR></LI> </UL> 14 to 18 hops shouldn\'t be required to Yahoo / AltaVista / and other major sites from these Tier 2-4 locations.

The VPN Panel will provide some perspective on the issues facing service providers as they specify and implement Virtual Private Network services. Issues of scaling, provisioning, network management, and interoperability will be discussed in the context of currently available solutions and proposals.

<UL> <LI> <STRONG>Japan Internet Exchange (JPIX)</STRONG> <BR><BR> The Japan Internet Exchange (JPIX) has been providing IX service since November 1997 as a commercial IX point in Tokyo. The number of customers and the traffic have been growing steadily, and the current status shows 36 connections with 650Mbps at its peak. <BR><BR> Japan\'s 24-hour Internet traffic pattern is very unique: the traffic peak exists at midnight and the bottom is at eight in the morning. This reflects the time period in which NTT\'s discount telephone rate plan is in effect. <BR><BR> Regarding peering, agreements are made between customers. Subscription to JPIX does not assure any peering agreement to be made with other customers. Though JPIX does not have any responsibilities for the agreement, it facilitates peering by means of multi-lateral peering arrangements. <BR><BR> As the first provision of the IX facilities is almost completely filled with the existing customer requirements, JPIX is going to introduce another switch in January 2000 to accomodate more customers. The initial switch has FDDI ports and the new switch will be equipped with Gigabit Ethernet and Fast Ethernet ports. In addition, JPIX is planning to introduce another IX in a different location in Tokyo. <BR><BR> We foresee that many more major US ISPs will be connected to JPIX in the coming year in parallel with the launch of new, Japan-US cable networks in mid-2000. Interconnected JPIX switches in multiple locations will meet more diverse requirements, especially from ISPs that request more carrier-neutral environments. <BR><BR></LI> <LI> <STRONG>Brazilian Internet Exchange (BIX)</STRONG> <BR><BR> The Brazilian Internet Exchange (BIX) has existed for several years, but only last year, due to the efforts of the Brazilian Engineering Steering Group and the Internet explosion in Brazil, have ISPs shown interest in connecting. The BIX is a public exchange supported by the Brazilian goverment and the Academic Network at Sao Paulo. It has nine members now, and four are in the process of establishing a connection. <BR><BR></LI> <LI> <STRONG>Ames Exchanges</STRONG> <BR><BR> This presentation will discuss exchange point configuration changes, POS and ATM beta program progress. progress on PAIX, and Ames Internet Exchange switch colocation. <BR><BR></LI> <LI> <STRONG>AADS</STRONG> <BR><BR> Included are a brief update on AADS traffic and increased high-speed demand in California. <BR><BR></LI> <LI> <STRONG>PAIX.Net</STRONG> <BR><BR> This presentation includes updates on remote peering, new sites, gigabit Ethernet, and exchange point status. <BR><BR></LI> <LI> <STRONG>Equinix</STRONG> <BR><BR>This presentation will highlight the general status of the Equinix Internet Business Exchange rollout, and a few Internet Research & Operations projects currently underway. <BR><BR> </LI> <LI> <STRONG>London Internet Exchange (LINX)</STRONG> <BR><BR> <BR><BR></LI> </UL>

This BOF gives the ARIN Advisory Council an opportunity to gather feedback from the NANOG ISP community regarding Micro Allocations. The BOF is not intended to set ARIN policy or for discussion of any existing ARIN policy. If this discusson is useful, it may be that the same BOF occurs at other regional registry meetings and other ISP functions. <BR><BR> <STRONG>What is a Micro IP Address Allocation?</STRONG> <BR><BR> Micro IP Allocations are small, portable, blocks longer than a /20, and perhaps as long as a /24 or longer, to multi-homed entities. It has been suggested that these micro allocations be out of some defined block of space that is known to ISPs (similar to the Swamp that we know and love). <BR><BR> <STRONG>Summary of the Lively Discussion at the Last ARIN Meeting</STRONG> <BR><BR> It has been discussed that when folks dual-home they currently often advertise the longer prefix into the global routing tables for anyone who will listen. Some say that micro allocations will not cause any additional route advertisements because they\'re already there. The counter argument to this is that all of these longer prefixes are still reachable via the ISP\'s aggregated route, and micro allocations would not be. <BR><BR> It was brought up that ISPs\' customers who want full Internet routes will have to buy heftier routers because of this. In addition, the ISPs will also have to do that themselves. It is the case, however, that if the block is well known, ISPs can aggregate it and announce the aggregate to their customers, thus keeping them from having to bear the burden of the added prefixes. It was also suggested that ISPs could filter on this block and perhaps begin charging folks who want the ISP to listen to the more specifics. <BR><BR> <STRONG>Agenda</STRONG> <UL> <LI> ARIN Advisory Council members who are present introduce themselves. <BR><BR></LI> <LI> Update on ARIN open policy meetings and who should attend. <BR><BR></LI> <LI> Micro Allocations - what are they? State purpose of the BOF (what the BOF is what the BOF is not). <BR><BR></LI> <LI> Abha Ahuja\'s overview of her address utilization study (routing table prefixes). <BR><BR></LI> <LI> Presentation of various micro allocation schemes. <BR><BR></LI> <LI> Discussion with attendees about the different schemes, their impacts, etc. <UL> <LI> Routing table impacts</LI> <LI> ASN depletion</LI> <LI> Other</LI> </UL>

<A HREF=\"hares/index.htm\">Presentation Slides</A>

Dynamic routing protocols such as RIP and OSPF essentially implement distributed algorithms for solving the Shortest Paths Problem. Can BGP be viewed as a distributed algorithm for solving some underlying problem? Contrary to popular belief BGP is not, in general, solving a shortest paths problem, since it allows policy-based metrics to override distance-based metrics, and enables autonomous systems to independently define their routing policies with little or no global coordination.<BR> <BR> I\'ll describe the \"Stable Paths Problem\" and argue that at some level, BGP is a distributed algorithm for solving this problem. The fact that BGP can actually fail to converge to a stable routing, as first observed by Varadhan et al., arises when the corresponding Stable Paths Problem has no solution. I\'ll give some examples of conflicting BGP policies that lead to BGP divergence, which would result in persistent route oscillations. The likelihood of such scenarios arising in practice is not known.

This update will discuss NSI\'s current status and future plans for root server and gTLD DNS infrastructure. <UL> <LI> Background of the NSI Registry</LI> <LI> gTLD RFP and plans/status for deployment of a COM/ORG/NET DNS worldwide infrastructure</LI> <LI> Performance Metrics <UL> <LI> Overview</LI> <LI> System</LI> <LI> Functional (i.e., DNS)</LI> </UL> </LI> <LI> Next-generation Technology <UL> <LI> Satellite-based zone file distribution</LI> <LI> 64-bit OS evaluation</LI> <LI> BIND 9</LI> <LI> DNSSEC</LI> </UL> </LI> </UL>

Numerous new protection and restoration schemes are emerging to augment traditional SONET/SDH methods. This talk will discuss and compare these approaches. Emphasis will be placed on \"Fast Re-Route\" (FRR) technology that is becoming availalbe through MPLS. Topics to be covered include: <UL> <LI> The trend from SONET to IP over DWDM</LI> <LI> The emergence of new protection schemes <UL> <LI> Optical Crossconnect-based protection</LI> <LI> IP-centric protection/restoration </LI></UL> </LI> <LI> A comparison of the options</LI> <LI> Introduction to FRR</LI> <UL> <LI> 50 msec line protection</LI> <LI> path restoration/re-optimization </LI></UL> <LI> FRR applications </LI> </UL>