Sat
Sun
Mon
Tue
Saturday, June 8, 2002
Topic/Presenter
Full Abstract

This tutorial introduces service providers to some more advanced BGP features and techniques to aid with operating their networks within the Internet. After a brief recap of iBGP, eBGP, and common attributes, the tutorial will look at the various scaling techniques available, when to use BGP instead of an IGP, and examine policy options available through the use of local preference, MED, and communities. The tutorial will then briefly cover some basic multihoming techniques, before finishing with a look at some of the facilities available for debugging problems in BGP networks.

Speakers
Philip Smith, Cisco Systems
Philip Smith has been with Cisco Systems for four years. He is part of the Internet Architectures Group, which is led by the CTO for Consulting Engineering. His role includes working with many ISPs in the Asia Pacific region, specifically in network design, configuration, and scaling, as well as providing training through an extensive ISP Workshop program. Prior to joining Cisco, Philip spent five years in several key network engineering and operations roles at PIPEX (now part of UUNET's global ISP business), the UK's first commercial Internet Service Provider. He was one of the first engineers working in the commercial Internet in the UK, and played a key role in building the modern Internet in Europe.
Recordings
Full Abstract

The session is intended for anyone responsible for updating and implementing routing policies of an ISP, including NOC personnel and technical management personnel who need to understand the process of publishing routing policy. The tutorial will discuss:

Publishing routing policy in the Internet Routing Registry (IRR). Expressing routing policies in the IRR using the Routing Policy Specification Language (RPSL), RFC-2622. Generating router configurations from policies stored in the IRR, using the Internet Routing Registry Toolset Specific topics include:

  1. RPSL objects
  2. Contact information objects (person, role)/usr/local/www/apache22/data/nanog/docs
  3. Specifying routing policy
    • aut-num object
    • route-set object

Speakers
Ambrose Magee, Ericsson
Ambrose Magee worked for the RIPE Network Coordination Centre Database Group from 1996 to 2001. While there, he wrote software and provided user support for Versions 2 and 3 of the RIPE Whois Database Server. He has presented tutorials on RPSL at RIPE meetings, at the Network Training Workshop preceeding the INET-2000 meeting in Japan, and at APNIC-12 in Taipei. Currently Ambrose works for the Ericsson Global Expertise Centre in Dublin as a Network Design Consultant in the Service Networks and IP Engineering Unit of the Network Consulting and Managed Services Department.
Recordings
Full Abstract

A provider's success is increasingly being influenced by its ability to monitor and engineer its traffic performance - both within its domain and between its domain and other AS's. Key data required for both inter- and intra-domain traffic engineering (TE) include information on routing, traffic loads, bandwidth, and path performance. This tutorial focuses on application of TE for inter-domain purposes. This includes short-term traffic management requirements such as debugging, congestion mitigation, and routing optimization; as well as long-term planning involving capacity planning, peering analysis, and load balancing. The first half of this tutorial provides an overview of techniques that can be used by large, complex networks to expand their visibility into and control of traffic moving between their network and other domains (it recaps key points from the NANOG24 Inter-domain Traffic Engineering tutorial). The second half of the tutorial provides specific examples and case studies of inter-domain TE from commercial networks, including MFN and Global Crossing. A case example from Exodus also demonstrates how data gathered for inter-domain TE can be used for intra-domain TE purposes, e.g., use of BGPNextHop in optimizing internal routing.

Speakers
Joe Abley, MFN
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.

Andrew Lange, CW
Andrew Lange is Principal Network Architect at Exodus, a Cable & Wireless Service. He designs and evaluates advanced network architectures and systems. Prior to joining Exodus, Andrew managed the Network Protocol Engineering and the QA/Test groups at GlobalCenter. These groups were responsible for the operations and future development of the GlobalCenter network.

Matthew Meyer, Global Crossing
Matthew Meyer is part of a team of network engineers evolving Global Crossing's multi-vendor MPLS-TE enabled network. He is team lead for a group that focuses on traffic engineering and network protocol design and analysis. Prior to working at GBLX, Matthew supported the NSFNET at Advanced Network Services (ANS), then shifted to backbone engineering and network optimization while at AOL and UUNET.

Josh Wepmen, Ixia
Josh Wepman is an applications engineer at Ixia. He was a senior engineer at Caimis, Inc., responsible for BGP routing and traffic (flow) analyses and for design of several traffic engineering applications. Previously, Josh served as a backbone engineer at UUNET, managing intra-domain routing and traffic engineering efforts.
Sunday, June 9, 2002
Topic/Presenter
Full Abstract

Speakers
Joe Abley, MFN
Andrew Lange, CW
Matthew Meyer, Global Crossing
Josh Wepmen, Ixia
Full Abstract

Speakers
Philip Smith, Cisco Systems
Full Abstract

Speakers
Ambrose Magee, Ericsson
Recordings
Full Abstract

This workshop describes technologies that enable IP service providers to offer tighter Service Level Agreements. The SLA parameters that need to be tightened are defined and the technologies that should be considered are described, together with the decision criteria on where each technology should be used. The workshop is based upon practical deployment experience and includes lab and deployment results. The specific technologies discussed are fast ISIS convergence and differentiated services. Consideration is also given to how these technologies should be deployed and operated. We demonstrate network designs to improve layer 3 routing convergence and traffic engineering, as well as give data to show the costs/benefits of these improvements. A paper based on this project has been published in Computer Networks.

Speakers
Clarence Filsfils, Cisco Systems
Recordings
Full Abstract

There are useful and quite general techniques that implementations can take advantage of for both IGP and MPLS convergence. Prior discussions at NANOG have focused on incremental SPF, but other techniques can be used as well. For example, a two-stage forwarding can allow the IGP route to change and the BGP routes that depend on it to follow with minimal changes to hardware forwarding information. Tradeoffs exist between using only an IGP vs. using MPLS. The IGP SPF takes order(LlogN), which is further reduced by incremental SPF. MPLS presents scaling limitations with respect to convergence due to the larger number of Constrained Shortest Path First (CSPF) computations that may be required if the set of unique constraints differs. These problems can be avoided through MPLS implementation techniques and network design techniques. Fast convergence for an IGP is a means to acheive faster restoration when a fault occurs. MPLS has restoration capabilities worth considering. MPLS fast reroute allows fast convergence with a complexity cost in terms of a larger number of LSPs being required. Standby LSP can support subsecond recovery with a bit less complexity. Rerouting LSPs from ingress can be done in seconds for most topologies. This latter case is where MPLS scaling issues come into play. SPF results caching and incremental CSPFs are among the techniques that can aleviate scaling problems, but these too have limits. There are problems to be solved to make incremental CSPF practical, such as finding similar CSPF results and quickly determining which links would differ for the purpose of incremental CSPF. Adjusting a CSPF for the current path of an LSP when considering rerouting it and the adjusted CSPF needed for disjoint paths present other complexities for which there are solutions. Topology and protocol usage also affects scaling on the IGP and of MPLS. Implications of area size and LSP tunneling are discussed.

Speakers
Curtis Villamizar, Avici
Recordings
Full Abstract

The Internet consists of about 13,000 autonomous systems (AS's) that exchange routing information using the Border Gateway Protocol (BGP). Network operators must have control over the flow of traffic into, out of, and across their networks. However, BGP does not facilitate common traffic engineering tasks, such as balancing load across multiple links to a neighboring AS or directing traffic to a different neighbor.

Solving these problems is difficult because:

  • The number of possible changes to routing policies is too large to exhaustively test all possibilities

  • Some changes in routing policy can have an unpredictable effect on the flow of traffic, and

  • The BGP decision process implemented by router vendors limits an operator's control over path selection.

We use empirical analysis of routing tables and traffic measurements from the AT&T backbone to derive operational guidelines for using BGP policy to perform traffic engineering tasks, such as shifting traffic away from a congested peering link. We show that a network operator can manipulate traffic efficiently by changing the routes for the small fraction of destination prefixes (and sets of related prefixes) responsible for the majority of traffic. We show how certain BGP policy changes can move traffic in a predictable fashion, despite limited knowledge about about the routing policies in neighboring domains. Finally, we show how operators can gain greater flexibility for traffic engineering by relaxing some steps in the BGP decision process (such as the use of AS path length) and ensuring that neighboring AS's send consistent advertisements at each peering location. These results enable network operators to use existing BGP features, such as BGP import policies, to accomplish common traffic engineering tasks.

An outline of the talk follows:
  1. Introduction
  2. BGP Traffic Engineering
    1. Border Gateway Protocol
    2. Tools for network-wide traffic engineering
  3. Data Collection
    • BGP routing tables
    • Flow-Level traffic measurements
  4. Overhead of routing changes
    • Simpler import policies: groups of related prefixes
    • Fewer routing changes: popular destinations
  5. Predictability of traffic flows
    • More stable traffic volumes: large traffic aggregates
    • Inbound traffic: limit globally visible changes
    • Tolerating routing changes: limit sensitivity to AS path
  6. Influence of neighboring domains
    • Ensuring consistent advertisements from neighbor AS's
      • Limiting the influence of AS path length
  7. Conclusion

A full draft of our writeup is available from:

http://nms.lcs.mit.edu/~feamster/papers/paper-nanog.pdf">http://nms.lcs.mit.edu/~feamster/papers/paper-nanog.pdf

Speakers
Jay Borkenhagen, AT&T Labs
Nick Feamster, MIT
Jennifer Rexford, AT&T Labs
Monday, June 10, 2002
Topic/Presenter
Recordings
Full Abstract

Since its introduction several years ago, the BGP community attribute [TCL96, CB96] has been used for several purposes. In this presentation, we describe a detailed study of today's utilization of the BGP community attribute [QB02a].

In the first part of the presentation we show that ISPs use the Community attribute for new purposes in the global Internet. We distinguish the two most common utilizations of the Community attribute: route tagging and traffic engineering.

  • Route tagging consists, for an ISP, in attaching Community values to a route received from an external peer in order to indicate the location that issued the route. Various types of locations are used in practice: geographic, interconnection point, and AS number, as well as the type of peer (customer/peering partner/transit provider).

  • Traffic engineering consists in attaching Community values to a route in order to influence its redistribution by downstream routers. Three types of Community values are used today to influence the redistribution towards specific peers or interconnection points: do not announce the route, prepend to the AS path or change the local preference.

In the second part of the talk we focus on the frequency of utilization of these two types of communities by presenting the results of a detailed analysis [QB02b] of the BGP table dumps from the RIPE RIS and RouteViews projects [RIS02, Mey02]. A first observation shows that Communities are widely used in the global Internet. For instance, nearly 50% of the routes advertised to the test router maintained by RIPE had at least one community attached. We have also classified communities that appear in the global Internet on the basis of the RIPE whois database [RIW02]. Based on this classification, we show that the Communities used for route tagging or traffic engineering represent a large part of the Communities present in the global Internet. Based on this analysis, it appears that the Community attribute is widely used. However, a drawback of this attribute is that each ISP needs to define and document its own Community values. This is flexible but requires a lot of error-prone manual configurations that are difficult to maintain. Furthermore, the limited size of the Community space has caused some ISPs to use Community values in their private AS or reserved space.

To cope with these limitations of the Community attribute, we describe an new type of extended community attribute [RTR01] called the redistribution communities [BCH^+02] that are currently being developed within IETF and can be used to support many of the current utilizations of the Community attribute in a more flexible manner. Furthermore, we show that the cost of supporting this new type of extended communities in a BGP router is minor based on our experience in implementing on the zebra platform [Quo02].

Acknowledgments

This work was partially funded by the European Commission within the IST ATRIUM project.

This work would not have been possible without the very useful information provided by the RIPE RIS project, the RIPE WHOIS database and the RouteViews project.

Referencess

[BCH^+02] O. Bonaventure, S. De Cnodder, J. Haas, B. Quoitin, and R. White. Controlling the redistribution of bgp routes. Internet draft, draft-ietf-ptomaine-bgp-redistribution-00.txt, work in progress, April 2002. [CB96] E. Chen and T. Bates. An Application of the BGP Community Attribute in Multi-home Routing. Internet Engineering Task Force, RFC1998, August 1996.

[Mey02] D. Meyer. Route Views Archive project. University of Oregon, http://archive.routeviews.org, January 2002.

[QB02a] B. Quoitin and O. Bonaventure. A survey of the utilization of bgp communities. Internet draft, draft-quoitin-bgp-comm-survey-00.txt, work in progress, February 2002. http://www.infonet.fundp.ac.be /doc/reports/Infonet-TR-2002-02.pdf.

[QB02b] B. Quoitin and O. Bonaventure. Utilization of the BGP Communities attribute. http://alpha.infonet.fundp.ac.be/anabgp, January 2002. Infonet Group, University of Namur, Belgium.

[Quo02] B. Quoitin. An implementation of the BGP Redistribution Communities in Zebra. http://www.infonet.fundp.ac.be/doc/tr/Infonet-TR-2002-0 3.html, February 2002. Technical Report TR-2002-3, Infonet Group, University of Namur, Belgium.

[RIS02] Routing Information Service project. Réseaux IP Européens, http://www.ripe.net/ripencc/pub-services/np/ris-index.h tml, January 2002.

[RIW02] Whois database. RIPE NCC, http://abcoude.ripe.net/ris/rawdata, January 2002.

[RTR01] S. Ramachandra, D. Tappan, and Y. Rekhter. BGP Extended Communities Attribute. Internet draft, draft-ramachandra-bgp-ext-communities-09.txt, Work In Progress, June 2001.

[TCL96] P. Traina, R. Chandrasekeran, and T. Li. BGP Communities Attribute. Internet Engineering Task Force, RFC1997, August 1996.

Speakers
Olivier Bonaventure, University of Namur, Belgium.
Bruno Quoitin, University of Namur, Belgium.
Recordings
Full Abstract

See Bill Woodcock's presentation at:

http://www.pch.net/documents/papers/peering-exch-transit-exch/NANOG-02.06-peering-trans.html">http://www.pch.net/documents/papers/peering-exch-transit-exch/NANOG-02.06-peering-trans.html

Speakers
Moderator - Bill Woodcock, Packet Clearing House
Panelist - Keith Mitchell, XchangePoint
Speaker - Philip Smith, Cisco Systems
Recordings
Full Abstract

The ARIN Public WHOIS server, a troubleshooting aid for applications that use resource assignment information, shows IP address space utilization. To coincide with the release of the new ARIN database and templates in summer 2002, ARIN will release a new WHOIS daemon. The new software offers many improvements, including a new format that is more machine-readable. This presentation will detail the enhancements that have been made, provide sample queries, and explain where users can test the new server.

Speakers
Ginny Listman, ARIN
Full Abstract

Avici Systems
Full Abstract

Now more than ever, Internet Service Providers are focusing on ways to increase the resiliency of their networks and, if at all possible, reduce their operating costs at the same time. Past research (Internet Service Providers and Peering, presented at NANOG 19, and A Business Case for Peering) demonstrates the economic tradeoffs of peering and highlight the simple but challenging first step: How to know who to talk with at an ISP to get peering set up This Peering BOF focuses on this first step using "Peering Personals." We solicit Peering Coordinators (before the meeting), asking them to characterize their networks and peering policies in general ways ("content heavy" or "access (eyeball) -heavy," "Multiple Points Required" or "Will Peer anywhere," "Peering with Content OK," etc.). From the answers we will select a set of ISP Peering Coordinators to present a 2-3 minute description of their network, what they look for in a peer, etc., allowing the audience to put a face with the name of the ISP. At the end of the Peering BOF, Peering Coordinators will have time to speak with Peering Coordinators of ISPs they seek to interconnect with. The expectation is that these interactions will lead to the Peering Negotiations stage, the first step towards a more fully meshed and therefore resilient Internet.

Speakers
Bill Norton, Equinix
Full Abstract

Join K Claffy and other members of the NANOG community to talk about your ideas for NANOG meetings (agenda topics, logistics) and the mailing list. We welcome your input!

Speakers
K Claffy, CAIDA
Recordings
Full Abstract

Speakers
Susan Harris, Merit Network
Robert Watson, Group Telecom
Recordings
Full Abstract

opportunity to discuss their perception of service provider requirements for core network design, especially in view of recent changes in the economy.

While presentation topics will be scoped somewhat loosely to avoid large overlaps, monotony and snoring, the panel members will be required to focus on technical solutions, technical presentations, and general directions versus their specific solutions.

Some potential discussion topics include:

  • Node reliability
  • Availability & survivability
  • Bandwidth and network expansion
  • High-speed packet sampling and filtering
  • capabilities
  • Future POP designs
  • Focusing on ROI from existing infrastructure.

Speakers
Moderator - Danny McPherson, TCB
Panelist - Puneet Agarwal, Pluris
Panelist - Eric Brendel, Chiaro
Panelist - Riad Hartani, Caspia
Panelist - Dave O'Leary, Juniper Networks
Panelist - Scott Poretsky, Avici
Recordings
Full Abstract

Speakers
Dave Katz, Juniper
Recordings
Full Abstract

In this talk, we analyze the BGP routes leading to root and generic Top Level Domain (gTLD) DNS servers and explore a protection mechanism for these critical routes. A fault or attack that creates a false route to these servers could deny access to millions of DNS zones or incorrectly redirect DNS queries to a malicious impostor. However, the temporary loss of a single server can be tolerated by the DNS. Our approach is to apply BGP AS path filters that make the BGP routes to these critical servers less dynamic. This provides strong protection against false routes, but some potentially valid back-up routes can be rejected. We have validated our design against over one year of BGP route logs from nine diverse ISPs. Our results show that routers using our AS path filtering could effectively detect the insertion of invalid routes, while maintaining reachability to the top level DNS servers.

Speakers
Randy Bush, AT&T Research
Allison Mankin, USC/ISI
Daniel Massey, USC/ISI
Dan Pei, UC Davis
Lan Wang, UCLA
Felix Wu, UC Davis
Lixia Zhang, UCLA
Xiaoliang Zhao, NCSU
Recordings
Full Abstract

In this talk, we take a look at where we are as a community with regard to BGP security. The session will walk through the history of the technology, techniques used, realistic risk assessments, and proposals in the queue for a BGP environment that is more resistant to attack (IETF's RPSEC, SBGP, and soBGP). The presentation is based on a paper (PDF) titled "BGP Risk Assessment" (updated 4/20/04) which was created for the operations community and submitted to the US National Security Council ISP BGP & DNS Working Group. (See related slides from Avi Freedman's NANOG 25 talk.) Note: on 4/20/04 the materials in this presentation were updated based on: http://www.uniras.gov.uk/vuls/2004/236929/index.htm

Speakers
Barry Raveendran Greene, Cisco Systems
Recordings
Full Abstract

In early 2002, Richard Clarke of the National Security Council/White House called a meeting among ISPs, device vendors, and some government agencies. Output from the working groups that were formed at the meeting will be incorporated into the President's cyber security policy.

This talk will present a summary of the recommendations from the working groups:

  • BGP & DNS
  • Infrastructure Hardening
  • Network Operations
  • Disaster Recovery
  • Address Accountability
  • Coordination
  • Enforcement and Privacy

Additional background on the purpose of the groups and the next steps will be presented, and some cautions will be raised about areas on which the government is concentrating, e.g., issues of address accountability and packet and route filtering.

Speakers
Avi Freedman, Akamai Technologies
Tuesday, June 11, 2002
Topic/Presenter
Recordings
Full Abstract

Increasing market demands for improved Internet availability is requiring ISPs to more quickly evaluate routers for network deployment. Typically, the focus of this evaluation has been on protocol conformance, interoperability, and scaling. While these parameters are critical for a successful deployment, none ensure router availability once deployed. ISPs and router vendors should now consider altering the paradigm of test and evaluation to focus on router stability in a multi-protocol environment. This is achieved by implementing a test program that includes automated regression testing, topology-specific configuration testing, convergence testing, stress testing, and longevity testing with multiple protocols simultaneously configured. This presentation will detail these components for integration into existing test programs as follows:

  1. Automated regression testing
    • Description
    • Benefits
    • Commercial Tools
    2. Large topology testing
    • Description
    • Benefits
  2. Convergence testing
    • Measurement techniques
    • Configurations
    • Commercial tools
  3. Stress testing
    • Description
    • Benefits
    • Procedure
    • Required automation
    • Commercial tools
  4. Longevity testing
    • Benefits
    • Procedure

Speakers
Scott Poretsky, Avici
Recordings
Full Abstract

Speakers
Susan Harris, Merit Network
Recordings
Full Abstract

Subject: Call for Participation - Smart Routing Panel Smart Routing Panel Description: The Internet is not resilient to two types of problems: outages and data flow quality degrading. Network outages are defined as periods where traffic to a portion of the network is down. A network is identified by a network prefix. Data flow quality degradation occurs when links or routers are so overloaded that traffic does not flow through at normal rates. Normally, data flow quality has to dramatically decrease for the Enterprise to be concerned. Some companies in industries such as stock trading or insurances have time critical information. Data flow in these companies must react quickly to data flow degradation. A group of vendors of "Smart Routing" products and services proposes to route around outages and areas of poor data flow. We are soliciting participants for a panel that will discuss this at NANOG 25 (June 9-11). This panel will focus solely on the technology issues in "smart routing" and "BGP". In the finest of NANOG traditions, we will eschew any marketing content in order to focus on the interesting technical issues in this area. We are looking for participants for this panel with deployed product. Each panel member will be required to prepare the answers to the questions below and to aid in preparing a the general panel discussions. Question 1 (parts A-F) and Question 2 will form the basis of the 1st panel session that will highlight the technology behind the smart routing. Question 3: "BGP issues that Smart Routing has highlighted" will be done in a second panel discussion. The format of this panel will be - Overview of Smart Routing - Presentations by Smart Routing Vendors - Q & A on Smart Routing - BGP issues Smart Routing has Highlighted - Q & A on BGP issues If you are interested in this panel, please contact me at [email protected]. Sue Hares [email protected] (734)222-1610 Participant Questionnaire: =========================== 1) Overview of Products 1-a) The smart routing product uses BGP to routes around "problems" in the network. We would like you to discuss the following 6 components of your product. Question 1-b through 1-g give detailed questions that will aid you in presenting these 6 components. - Is your product a box or a service or both ? (Question 1-b) - Definition of "quality" of data flow (Question 1-c) - Detection of traffic flow problems (Question 1-d) - Building up of database of alternative BGP routes (Question 1-e) - Policy engines to tailor the "re-routing" to the customers' needs (Question 1-e) - Traffic steering capability (Question 1-f) - Interaction with other products (Question 1-g) Please indicate which of the following methods your product defaults to. Also indicate which of these methods your product can support. Please indicate how your product does each of these 5 tasks. For the database item, please indicate if both history and current data is being used. 1-b) What do you sell? - Box or service or both? - Do you utilize a POP in your topology? - What is in your POP? Is it 7x24x365? - Do you have a NOC for your service? - What does your product change? - IBGP routes in the Enterprise - Data traffic flow - Do you use tunneling techniques to points inside your network to "re-route" traffic to the correct site? - Do you characterize data flows by applications? - Management information - Do you tunnel management information to a management server? - What reports to you provide? 1-c) How does your product define "quality" for the Enterprise customer? - What factors are measured for quality of data flow through the Internet? - What factors are common with other Smart Routing vendors and what parts of your product are unique? - What is the default mechanism your product utilizes to set quality? - Who sets default quality - the product (by discovery) or the customer? Why did you choose your defaults? - Is the customer required to set-up quality definitions? - Is the policy you set for an enterprise set by destination address? - As single prefix or a group of prefixes? - Is the policy you set for an enterprise set on something in the packet beside the destination address? - By source address, destination address? - By other things in the IP packet? - Does the product include work load characterization mechanisms? - Application prioritization, - Traffic mixture statistics, or - Traffic type based queuing Please provide any additional information you consider as part of "quality" that these questions have not indicated. 1-d) The detection of traffic flow problems has been done with tools that ping, trace-route, sniffing on data traffic, or query statistics in the network. These tools may make use of the ICMP network functions or may be application protocols based in UDP or HTTP information. - IP Ping packages (both ICMP and non-ICMP) to determine delay in programs, - Do you use an ICMP (normal ping) program? - Do you use a proprietary UDP based ping (end to end query)? - Do you use a proprietary HTTP based ping (end-to-end query)? - How do you select the locations to be queried via ping or application UDP program? Are you using your web sites or customer machines? If you are using web sites, who owns the web site or the content? - Do you use a traceroute like packages to determine the hop-by-hop characteristics of the route? - Is the traceroute package based in ICMP, UDP, or other network protocols?] - Do you utilize a MPLS Trace-route package? - Do you display this information in visual form? Is this visual form in text or graphical? - Do you do data traffic flow monitoring or packet sniffing on a LAN? - Why do you utilize this in your product? - Do you tunnel to obtain the traffic or "listen" to wire packets? 1-f) Traffic steering and route flapping -Traffic steering involves steering traffic by inserting information in to the IBGP mix. Please indicate which of these functions you support. - Insertion of a prefix with a better local_pref, - Insertion of a longer prefix, - Insertion of BGP communities to allow the enterprise to route around the difficulty, or - Insert of changes to AS Path length. - What is your default? - If you use the insertion of a prefix with a better LOCAL_PREF value, how do you keep from the new route being the "better" route and IBGP killing the supporting route? - If you inserts two longer prefixes, what happens if the two longer prefixes are in the routing traffic already? (for example a /16 is replaced by 2 /17s) - How do you prevent flapping between two different paths for traffic flows? - How often do you change traffic flows directions (route changes)? - Why would you change routes or exit points with the Enterprise? 1-g) how does your product interact with other products in the Enterprise? - Do firewalls impact your product? - Do you run through a firewall? - Does the security or the traffic filters impact your product? - How does your product interact with existing routers? - Does it receive BGP routes? Does it send BGP routes? - Does it receive statistics? - How does your product interact with web servers or web caches? - How does it improve the web cache update? (Please be specific as this is a technical audience.) - How does the product improve web server traffic? - Does your product interact with packet optimizers? 2) What is it worth it to Customers? 2-a) Why Does the Enterprise buy smart routing? What benefits does it provide to the Enterprise customer? 2-b) Multi-homing of Enterprises - How many connections do individual Enterprises have? - Does the number of connections vary widely? - What is the range? 2-c) Return on Investment for Customer - What improvements to traffic flow can you obtain? - How can you prove to your customers that you are improving traffic? - Using the box, can or should the customer reduce the number of required connections to the Internet? 2-d) What performance problem are you fixing? - Tier 1 providers claim 5 9s of performance, where is the problem? In the "middle mile " between service providers? At the edge on access? In the Tier 1 or Tier 2 or Tier N service provider? 3) BGP issues that "Smart Routing" has highlighted 3-a) BGP selecting the Best route - What percentage of time does BGP pick the optimum route for data flow? - Is the less efficient usage based on - No policy based so the select devolves on BGP tie breaking? - Explicit policy (go through this AS) - AS Path Length policy? - How many months of BGP problem evaluation have you had? 3-b) does BGP Convergence issues cause some of these problems? - Do you see any results of the IBGP persistent route oscillation? - Do you see any MPBGP Multicast routes? http://www.multicasttech.com/status/index.html indicates that there are over 350 AS that are doing multicast. - What is the effect of Non-Stop-Forwarding on Smart Routing? At times the NSF will cause the control plane to go while you are making measurement? Do you require any coupling between the data plane and the control plane? 3-c) MPLS and BGP - What does the impact of MPLS and GMPLS cores on Smart Routing? - Do you see any Layer 3 VPNs in use in the Enterprise or by the service providers connecting to Enterprises? - Have you encountered MPLS forwarding in the Enterprise? - If so, what type: link layer or BGP VPNs? - If not, is the enterprise using Frame Relay or ATM

Speakers
Moderator - Sue Hares, NextHop
Panelist - Robert Bays, Proficient
Panelist - Aaron Britt, Opnix
Panelist - Daniel Golding, Sockeye
Panelist - Jeremy Johnson, netVmg
Panelist - Mike Lloyd, RouteScience
Panelist - Brandon Ross, Sockeye
Full Abstract

Panel's second agenda:

10:45-11:20 a.m. - BGP Issues

11:20-11:35 a.m. - Q & A

Speakers
Sue Hares, NextHop
Recordings
Full Abstract

Speakers
Dave O'Leary, Juniper
Dave O'Leary is Director of Consulting Engineering at Juniper Networks, where he has worked for over 4 years. He works with a variety of service provider customers on introduction of new technologies into the network. He has over 18 years of industry experience in developing and deploying Internet technologies and services.
Download the full event calendar