^ Top

NANOG 34 Agenda

All Times are in Pacific Daylight Time.

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, May 15 2005
Time/Webcast:Room:Topic/Abstract:Presenter/Sponsor:Presentation Files:
1:30pm - 3:00pmCascade II<BR>Mezzanine Level

Tutorial: Best Practices for Determining the Traffic Matrix in IP Networks<BR>Level: Intermediate

Knowledge of the amount of traffic between source and destination pairs of a network is crucial to fundamental operational tasks such as capacity planning, traffic engineering, and peering management. Router vendors, third parties, academic researchers, and ingenious network engineers have devised multiple ways of collecting and estimating traffic matrices. This session presents an overview of applications of traffic matrices and operational experiences with the various approaches, including Netflow-based methods, mathematical estimation models, and MPLS (both RSVP and LDP) methods. Emphasis will be on practical experiences with each method.

View full abstract page.
Speakers:

  • Thomas Telkamp, Cariden
  • Thomas Telkamp is responsible for deploying Cariden products, and guides product development. Previously, he worked for Global Crossing as Director of Network Engineering, Director of IP Global Architecture, and Director of Networking Research. Before joining Global Crossing, Thomas worked as a consultant at AT&T-Unisource Communications Services, SURFnet Expertise Centrum, SURFnet, DANTE and Wunderman Cato Johnson. Thomas\' professional interests include network modeling and analysis, traffic characterization and traffic engineering.
youtubeBest Practices for Determining the Traffic Matrix in IP Networks - Level: Intermediate
pdfThomas Telkamp - Best Practices(PDF)
1:30pm - 3:00pmCascade I<BR>Mezzanine Level

Tutorial: Bridges, Routers, Switches, Oh My!<BR>Level: Introductory/Intermediate

This session demystifies the conceptual issues in moving data across multiple hops. We give an overview of, and contrast the functionality of these technologies, including an overview of link state routing (used in OSPF and IS-IS), spanning tree (used in bridging and switching), distance vector (used in RIP), and path vector (used in BGP).

View full abstract page.
Speakers:

  • Radia Perlman, Sun
  • Radia Perlman is a Distinguished Engineer at Sun Microsystems. Some of her contributions to the industry include inventing the spanning tree algorithm used by bridges and switches, and many of the algorithms necessary to make link state routing (IS-IS and OSPF) scalable and robust. She is the author of \'Interconnections\' and coauthor of \'Network Security.\' She has taught graduate and undergraduate level courses at Harvard and MIT, and is currently an adjunct faculty member of the University of Washington. She has about 60 issued patents, a Ph.D. in computer science from MIT, and an honorary doctorate from KTH, the Royal Institute of Technology of Sweden.
youtubeBridges, Routers, Switches, Oh My! Level: Introductory/Intermediate
pdfRadia Perlman - Bridges, Routers, Switches, Oh My!(PDF)
3:00pm - 3:30pmCascade Foyer North<BR>Mezzanine LevelBreak
3:30pm - 5:00pmSt. Helens<BR>Mezzanine Level

BGP Analysis Tools

Recently two BGP tools have been released to the public, BGP::Inspect and Link-Rank. The common goal is to make the vast quantities of the University of Oregon\'s Route Views data easily accesible to the network operator and research community. Link-Rank visualizes BGP routing changes, while BGP::Inspect answers various useful queries, e.g., most active ASes and most active prefixes, as well as prefixes that exhibited the most number of changes in their OriginAS. Roughly half of this BOF will be a tutorial describing the tools\' basic functionality and a number of new usage features. The second half offers an interactive hands-on opportunity for interested users to try them out, as well as to collect feedback from the operator community for future improvement. Attendees are encouraged to suggest analysis problems that may have arisen in their work and test whether the tools would be effective in analyzing these events.

View full abstract page.
Speakers:
  • Manish Karir, Merit Network.
  • Mohit Lad, UCLA.
  • Dan Massey, Colorado State University.
  • Lixia Zhang, UCLA.
pdfMohit Lad Presentation(PDF)
3:30pm - 5:00pmCascade II<BR>Mezzanine Level

Tutorial: BGP Techniques for Service Providers

This tutorial introduces service providers to some more advanced BGP features and techniques to aid with operating their networks within the Internet. After a 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 then looks at common deployment scenarios as used in ISP networks, before finishing off with some of the newer features available.

View full abstract page.
Speakers:

  • Philip Smith, Cisco Systems
  • Philip Smith joined Cisco Systems in January 1998. He is a member of the Service Provider Architectures Group of Consulting Engineering, within Corporate Development. His role includes working with many ISPs in the Asia-Pacific region and the rest of the world, specifically in network strategies, design, technology, and operations, as well as helping with network configuration and scaling. Other areas of interest also include Internet routing, Internet protocols, IPv6, and encouraging the growth of the Internet around the world. Prior to joining Cisco, he spent five years 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 UK Internet, and played a fundamental role in building the modern Internet in the UK and Europe. Philip is co-author of \'Cisco ISP Essentials,\' published by Cisco Press. He holds a Doctor of Philosophy and has a First Class Honours Degree in Physics. He lives in Brisbane, Australia.
youtubeBGP Techniques for Service Providers
pdfPhilip Smith BGP Techniques for Service Providers(PDF)
3:30pm - 5:00pmCascade I<BR>Mezzanine Level

Tutorial: Challenges in Network Security Protocols<BR>Level: Introductory/Intermediate

This tutorial gives a quick overview of the basics of network security, including cryptography, authentication, key distribution, and some web basics. It also talks about what is difficult. The real difficulty isn\'t the cryptography, but basic system issues, especially considering that people are part of the system. We cover topics such as the functional differences between PKI-based systems and Kerberos-like systems, PKI trust models, and enough cryptography to impress a date.

View full abstract page.
Speakers:

  • Radia Perlman, Sun
  • Although Radia Perlman is most well known for her work in bridging and routing protocols, she has also made significant contributions to network security, including sabotage-proof routing, strong password protocols, PKI models, analysis and redesign of the IPsec authentication handshake (IKE), efficient revocation of certificates, and secure deletion of data. Radia is a Distinguished Engineer at Sun Microsystems. She is the author of \'Interconnections\' and coauthor of \'Network Security,\' as well as being a series editor for Prentice Hall. She has taught graduate and undergraduate level courses at Harvard and MIT, and is currently an adjunct faculty member of the University of Washington. She has about 60 issued patents, a Ph.D. in computer science from MIT, and an honorary doctorate from KTH, the Royal Institute of Technology of Sweden.
youtubeChallenges in Network Security Protocols - Level: Introductory/Intermediate
pdfRadia Perlman - Network Security Protocols(PDF)
5:30pm - 7:00pmCascade II<BR>Mezzanine LevelWelcome Reception!
7:30pm - 9:30pmCascade II<BR>Mezzanine LevelOpen Community MeetingSpeakers:

  • Betty Burke, Merit Network
  • Everyone is invited to join us in Seattle for several importanat follow-on meetings to our Las Vegas community meeting. Sunday evening\'s presentations will provide food for thought for Tuesday, when informal afternoon and evening meetings will give us an opportunity for open community discussion. <BR><BR> <B>Sunday evening: Community Update</B> <BR><BR> Our agenda will include: <OL> <LI> Merit budget update (Betty Burke)</LI> <LI> Spring 2005 Program Committee survey results (Steve Feldman, PC Chair)</LI> <LI> Analysis of previous meeting surveys (Merit)</LI> <LI> Update on NANOG list-admin activities (Martin Hannigan) <BR><BR></LI> </OL> Tuesday afternoon and evening: Community Dialog On Tuesday afternoon we\'ll work together to resolve open issues remaining from Sunday evening. By Tuesday evening, we\'ll be ready to prepare an action plan for next steps to take in the continuing evolution of NANOG. <HR> <B>Steve Gibbard\'s notes from Tuesday\'s meeting:</B> <BR><BR> Merit had many hours scheduled for discussions on the future of NANOG today. After less than 45 minutes, we agreed to all \"declare victory and enjoy a beautiful afternoon.\" <BR><BR> Mike McPherson, Merit\'s President, presented Merit\'s draft of the NANOG bylaw proposal. Merit\'s draft is quite similar to my version of the NANOG Reform bylaw proposal presented on these lists a few weeks ago, being the same word for word in some places with some differences in others. <BR><BR> Merit invited Steve Feldman, the program committee chair, and Marty Hannigan, who they had somehow decided was a representative of the NANOG Reform group, to comment on it. Steve said the program committee was willing to accept the proposal and that he was glad Merit was now thinking about what NANOG should be. Marty disclaimed representation of the NANOG Reform group (rightly -- he wasn\'t part of the NANOG Reform proposals), but said he agreed with Merit\'s proposal too. <BR><BR> As the most recent editor of the NANOG Reform bylaws, I thanked Merit for their proposal, and said I thought it was an improvement over by own. <BR><BR> Various others expressed support for the Merit proposal. <BR><BR> Mitchell Rose expressed a concern that the summary of the Merit proposal on the slides referenced NANOG as an organization for Internet service providers, and appeared to be excluding other large network operators. Merit agreed that this could be changed, but it appears that was wording only in the Powerpoint summary and not in their actual draft. <BR><BR> Vijay Gill said we\'re all crazy and should just go back to how things were. Nobody seemed willing to publicly agree with him. <BR><BR> Daniel Karrenberg suggested that since we all seemed to be agreeing with each other, we should \"declare victory and go home.\" There seemed to be general agreement with that. <BR><BR> So, it looks like we\'ll end up with the Merit draft or something pretty close to that, which I think is the right outcome. We should have \"steering committee\" elections sometime this summer, with the committee in place in time for the fall NANOG. I told Susan Harris that I\'d be happy to help with wording as they finalize it. She seemed receptive to that idea. <BR><BR> -Steve
  • Steve Feldman, CNET.
  • Martin Hannigan, VeriSign.
pdfMarcia Mardis - Attendee survey analysis(PDF)
pdfSteve Feldman - Program Committee report(PDF)
Monday, May 16 2005
Time/Webcast:Room:Topic/Abstract:Presenter/Sponsor:Presentation Files:
8:00am - 9:00amGrand Foyer<BR>Grand LevelContinental Breakfast
9:00am - 9:15amGrand Ballroom II-III<BR>Grand LevelWelcome, IntroductionsSpeakers:

  • Steve Feldman, CNET
  • Steve Feldman has been involved in computer networking since 1978. He has worked in software development and network engineering for Tymnet and MFS/Worldcom, where he was the principal architect for the MAE Internet exchanges. Since then, he has gone on to work for several startups and acted as an independent consultant, and is now a network engineer for CNET Networks. Steve received B.S. and M.S. degrees in Computer Science from the University of California at Berkeley. He has chaired the NANOG Program Committee since February 2005.

  • Chris Quesada, Switch and Data
  • Christopher Quesada has an extensive background in the telecommunications and networking industry. Chris has worked in product development, engineering and marketing for such companies as DIGEX, Intermedia, Cogent Communications, MFN/Abovenet and, currently, Switch and Data. He received his B.A. from George Mason University in 1996. As an ardent supporter of NANOG, he was chosen to represent Switch and Data as Host speaker and coordinator of NANOG 34.
youtubeWelcome, Introductions
9:15am - 9:35amGrand Ballroom II-III<BR>Grand LevelRegional Internet Registry/WSIS UpdateSpeakers:
  • Ray Plzak, ARIN.
pdfRay Plzak Presentation(PDF)
youtubeRegional Internet Registry/WSIS Update
9:35am - 10:05amGrand Ballroom II-III<BR>Grand Level

Design Decisions and Architecture Analysis of a Global 10G Backbone (We Do it, so You Don\'t Have To)

This talk will cover the key technical and business drivers behind the construction of a global 10G backbone, including some of the financial analysis behind build vs. buy, lessons learned, policy and nodal architecture design necessary to scale a backbone from carrying under 45 Gigabit/sec of traffic three years ago, to over 250 Gigabit/sec of traffic now, while reducing overall OPEX.

View full abstract page.
Speakers:
  • Vijay Gill, AOL Time Warner.
youtubeDesign Decisions and Architecture Analysis of a Global 10G Backbone
pdfVijay Gill Presentation(PDF)
10:05am - 10:35amGrand Ballroom II-III<BR>Grand Level

VoIP Overview for Operators

This talk provides an overview of VoIP for operators that covers some of the issues and challenges confronting the evolution of VoIP. Topics include a brief history of the evolution of how we got here, issues and challenges such as public and private ENUM, security, and \'quality\' needs/desires of applications derived from VoIP technologies such as SIP.

View full abstract page.
Speakers:
  • Eugene Lew, NeuStar.
pdfEugene Lew Presentation(PDF)
youtubeVoIP Overview for Operators
10:35am - 11:00amGrand FoyerBreak
11:00am - 11:30amGrand Ballroom II-III<BR>Grand Level

Securing Carrier VoIP: Session Border Control

There is still some debate in the SIP community about the best way to protect the service, and whether there\'s really a need for Session Border Controllers. Are they good or evil? This presentation will focus on the current practice for carrier VoIP security, the need and role for Session Border Controllers, and some lessons learned from current deployments.

View full abstract page.
Speakers:

  • Hadriel Kaplan, Acme Packet
  • Hadriel is a Senior Product Manager for Acme Packet. Don\'t worry though - he may be a Product Manager but he\'s technical. He is also a Solutions Architect within the VoIP Security Architecture group of Acme Packet, in charge of SIP security and attack protection. Prior to Acme Packet, he was a Senior Product Manager at Avici Systems, and before that he was a Senior Managing Engineer in the innovations lab research group of Nortel Networks, in charge of a group responsible for VoIP interoperability and standards compliance.
pdfHadriel Kaplan Presentation(PDF)
youtubeSecuring Carrier VoIP: Session Border Control
11:30am - 11:45amGrand Ballroom II-III<BR>Grand Level

The Spoofer Project: Inferring the Extent of Internet Source Address Filtering on the Internet

By forging or \"spoofing\" the source address of an IP packet, a malicious user or compromised host can send packets toward a victim anonymously or employ reflector attacks. This talk presents an Internet-wide active measurement spoofing project. Clients source valid, bogon and martian spoofed UDP packets to determine source address filtering policy. We infer filtering granularity by performing adjacent netblock scanning. Our results are the first to quantify the extent and nature of filtering and the ability to spoof on the Internet. Approximately 23% of the observed netblocks and autonomous systems permit spoofing or employ automated configuration methods that allow partial spoofing. Projecting this number to the entire Internet, an approximation we show is reasonable, yields over 108M spoofable addresses and 4,000 spoofable networks. Our findings suggest that a large portion of the Internet is still vulnerable to spoofing and concerted attacks remain a serious concern.

View full abstract page.
Moderators:
  • Robert Beverly, MIT.
pdfRobert Beverly Presentation(PDF)
youtubeThe Spoofer Project
11:50am - 12:05pmGrand Ballroom II-III<BR>Grand Level

Trust Reflection: A Distributed Approach to PGP Key Signing at Multi-Day Events

PGP is a system for encrypting and verifying the authenticity of information, and is commonly used as a tool to sign and encrypt e-mail. For PGP to be useful, a means of obtaining and distributing trust in public keys is required: in PGP, this is done by adding signatures to keys to build a \"web of trust\". Key signing parties are one way to build an effective web-of-trust. Big Key Signing parties are tedious: lots of hexadecimal, and often little attention to the important matter of verifying identities. Big key signing parties are also awkward to schedule. This presentation proposes an alternative approach: to hold several, smaller key signing parties which can be interconnected by individuals who attend more than one of them. This approach is being followed for PGP Key Signing at NANOG34.

View full abstract page.
Speakers:
  • Joe Abley, ISC.
pdfJoe Abley - PGP Key Signing(PDF)
youtubeTrust Reflection: A Distributed Approach to PGP Key Signing at Multi-Day Events
12:05pm - 1:30pm Lunch
1:30pm - 2:00pmGrand Ballroom II-III<BR>Grand Level

Anycast Measurements Used to Highlight Routing Instabilities

It appears that anycast illustrates and exacerbates certain types of routing instabilities. We performed a series of measurements on both Planetlab and the internet at large in an effort to better understand the dynamics of routing through the anycast perspective. We found that anycast highlights the fact that routing stability is highly variable depending on network vantage point, with some ASs seeing a wildly varying situation. We also found that routing surveys done using planetlab nodes must be done very carefully if they are to be generalized to the internet at large. Recently, our observations have been validated by RIPE using very different data. By NANOG we hope to also be able to show causes of the varying kinds of instability we have seen. <BR><BR> <A HREF=\"http://soy.dyndns.org/~peter/projects/research/anycast/nanog/\">http://soy.dyndns.org/~peter/projects/research/anycast/nanog/</A>

View full abstract page.
Speakers:
  • Peter Boothe, University of Oregon.
  • Randy Bush, IIJ.
youtubeAnycast Measurements Used to Highlight Routing Instabilities
2:00pm - 2:30pmGrand Ballroom II-III<BR>Grand Level

DNS Anycast Stability

Intuitively prefixes announced at multiple locations in the BGP topology will have more potential paths than those announced conventionally. Again intuitively this would amplify instabilities inherent in BGP routing as used in the Internet today. The presentation combines measurements of anycasted DNS root service with observations of BGP routing to document the status quo and ask more questions.

View full abstract page.
Speakers:

  • Daniel Karrenberg, RIPE NCC
  • Daniel Karrenberg is one of the founders of RIPE and led the establishment of the RIPE NCC, the first of the RIRs; before that he helped to establish EUnet, the first pan-European ISP. Daniel currently serves the RIPE NCC as Chief Scientist; his interests include Internet measurements, the development of the DNS, routing security and the evoloution of what others often call \"Internet Governance\".
pdfDaniel Karrenberg Presentation(PDF)
youtubeDNS Anycast Stability
2:30pm - 3:00pmGrand Ballroom II-III<BR>Grand Level

Building Nameserver Clusters with Free Software

This presentation describes a method of building multi-host clusters for DNS service using free software. Services are provided on two more hosts, and reachability to a service address is signalled to the rest of the network from each server. In this way the service is anycast within an OSPF area. The F root nameserver is operated by ISC using nameserver clusters constructed in this manner. Issues of service monitoring, troubleshooting, stateful (TCP) transactions and necessarily-unicast, administrative functions (zone transfers, system maintenance) are discussed in some detail. The limitations of the technique with respect to load balancing, the use of other (non-DNS) protocols and operational deployment are also described.

View full abstract page.
Speakers:
  • Joe Abley, ISC.
youtubeBuilding Nameserver Clusters with Free Software
pdfJoe Abley - Building Nameserver Clusters(PDF)
3:00pm - 3:30pmGrand FoyerBreak
3:30pm - 4:00pmGrand Ballroom II-III<BR>Grand Level

Anatomy of a Leak: AS9121 (or, \"How We Learned To Start Worrying and Hate Maximum Prefix Limits\")

Large-scale leaks have caused routing problems on the Internet in the past. On Dec 24, 2004, AS9121 announced over 100K routes to their peers, resulting in widely propagated invalid routes. Many large networks carried over 25K bad paths during the event, and some as many as 100K. Using BGP updates from approximately 80 peering sessions during the event, we analyze the event including the worst-hit networks, and the networks that spread the most bad paths. We find that network distance from AS9121 and maximum prefix settings on BGP sessions were not enough to prevent networks from carrying the bad prefixes. Finally, we review operational lessons learned (from feedback from involved networks) and make suggestions on future mitigation strategies.

View full abstract page.
Speakers:
  • Alin C. Popescu, Renesys Corporation.
  • Brian J. Premore, Renesys Corporation.
  • Todd Underwood, Renesys Corporation.
youtubeAnatomy of a Leak: AS9121
pdfTodd Underwood Presentation(PDF)
4:00pm - 5:00pmGrand Ballroom II-III<BR>Grand Level

Panel: XSP Security Vulnerabilities Panel

Increased threats and security demands by customers and the operator community have led to pressure on operators and providers to provide a more secure Internet. This panel will examine network-related vulnerabilities and their impact on the Internet operational community at large.

View full abstract page.
Moderators:
  • Martin Hannigan, Versign.
Panelists:
  • Patrick Gilmore, Akamai Technologies.
  • Aaron Hughes, Terremark/NOTA.
  • Chris Malayter, TDS Telecom.
  • Chris Morrow, UUNET.
  • Richard Steenbergen, nLayer Communications.
pdfMartin Hannigan - XSP Security Vulnerabilities(PDF)
youtubePanel: XSP Security Vulnerabilities Panel
5:00pm - 7:30pmGrand Ballroom II-III<BR>Grand LevelBeer n Gear
  • Sponsors Alcatel; Arbor Networks; Cariden; Cisco Systems; Internap; Juniper Networks; Redback Networks.
  • Sponsors
  • 7:30pm - 9:00pmCascade II<BR>Mezzanine Level

    INOC-DBA BOF with INOC-DBA Operators

    The INOC-DBA (Inter-NOC Dial-by-ASN) hotline phone system connects the network operations centers of network operators around the world in a closed VOIP system. The system\'s name is derived from the fact that the dial plan employs the AS Numbers of the participating organizations. To call the network operations center of another carrier or ISP, a user simply picks up the phone and dials their AS Number, which rings straight through to the other network\'s NOC or specific individuals there.

    View full abstract page.
    Moderators:

    • Gaurab Raj Upadhaya, PCH
    • Gaurab Raj Upadhaya is currently employed as Internet Economics Analyst / Staff Engineer, at Packet Clearing House, a research non-profit based in Berkeley, California. He runs the hotline phone system, PCH INOC-DBA, for service providers. He also works mostly in Internet backbone operations, analysing peering relationships between operators and roles of Internet Exchange Points in different parts of Asia. Much of the work involves training ISPs in developing countries about best practices on network operations. He initiated the Nepal Internet Exchange (npIX) and currently serves as its voluntary CEO.
    pdfGaurab Raj Upadhaya Presentation(PDF)
    7:30pm - 9:00pmCascade I<BR>Mezzanine Level

    Peering BOF IX

    At this Peering BOF we will explore one of several debates the Peering Coordinator community has volunteered as the most important and interesting issue facing the community today. Through debate, the competetive juices have proven to highlight the strongest arguments on both sides of a peering issue, so we will hopefully educate and entertain at the same time. In addition we will have the opportunity for those who have travelled a great distance to introduce themselves to the group, and raise ad hoc issues of interest to Peering Coordinators. <HR> From: Bill Norton Subject: Peering BOF IX at NANOG in Seattle - The Great Public vs. Private Peering Debate Hi all - Just wanted to invite you all to the upcoming Peering Birds-Of-a-Feather session at the upcoming NANOG, and give you a flavor of a couple of the topics to be discussed... Peering Introductions ------------------------------- For Peering Coordinators who would lke to introduce themselves to the North American Peering Coordinator Community, we have some time set aside for you to introduce yourself and share with the Community: Company Name and Contact Information, AS#, Where you are peering or expect to peer in the future, What you are looking for in a peer, and Why people should be interested in peering with you. We have found these face-to-face interactions helps facilitate peering, particularly for folks coming in from overseas. It helps to bring network maps, and lots of business cards. If you email [email protected] this information I will make a slide with your contact information on it that will show up behind you are you speak. The Public vs. Private Peering Debate -------------------------------------------------------- We have recruited two Peering Coordinators to articulate the two sides of the Great (Public vs. Private) Peering Debate. They have graciously agreed to share with the audience the Strongest Arguments for Public Peering (Maurice Dean), and the Strongest Arguments for Private Peering (Peter Cohen). Each side will have a few minutes to present their case, then a few minutes to attack the claims made by the other side and/or reinforce their own side of the argument as needed. We will perhaps add a few minutes in the middle for a couple of limited scope audience questions; those to help the speakers clarify a point (no speeches or attacks here). Both sides will then summarize their argument and the audience will be asked to vote for which side made the more compelling case. Audience Discussion ------------------------------- As we did last Peering BOF, we will open the floor to discussion, focusing on points that one or both sides failed to make, or failed to make strongly enough, that would have perhaps made a difference in the audience vote. Background ------------------ I researched this issue with a subset of the Peering Coordinator Community and shared the early results at the RIPE EIX WG meeting. If the discussions there are any indicator, I think we are in for an interesting and educational community discussion here. Below is an excerpt of the public vs. private peering arguments I heard from the Peering Coordinator Community and shared at the RIPE EIX WG meeting. I agree with the Peering Coordinators who believe the answer for most ISPs is a hybrid of public and private peering. I also agree that perhaps there sometimes emerges a transition based upon scale and strategic intent, but we will see what the community comes up with at the BOF. Bill PS - I cut and pasted the text below from the \"The Great (Public vs. Private Peering) Debate: Peering at 10G\" white paper that I am using to document these debates as they relate to 10 Gigabit-per-second Ethernet Peering. I am still looking for reviewers to provide feedback here BTW...If you are interested in this stuff and can spend a little time to provide feedback, send email to [email protected] When I feel more comfortable that I have it right, I will make the paper freely available to anyone who would like a copy. ----------------------------------------------------------------------------------- : : The Top 4 Reasons Public Peering is better than Private Peering 1. Aggregation Benefits a. A network can easily aggregate a large number of relatively small peering sessions across a single fixed-cost peering port, with zero incremental cost per peer. (Private peering requires additional cross connects and potentially an additional interface card, so there are real costs associated with each incremental peering session.) Small peering sessions often exhibit a high degree of variability in their traffic levels, making them perfect for aggregation. Since not all peers peak at the same time, multiple peers can be multiplexed onto the shared peering fabric, with one peers peak traffic filling in the valleys of another peer\'s traffic. This helps make peering very cost effective: \"I can\'t afford to dedicate a whole gigE card to private peering with this guy, but public peering is a no-brainer.\" b. Public peering ports usually have very large gradations of bandwidth: 100Mbps Ethernet upgrades to 1Gbps Ethernet, which upgrades to 10Gbps Ethernet. With such large gradations, it is easier for smaller peers to maintain several times more capacity via public peering than they are currently using, which reduces the likelihood of congestion due to shifting traffic patterns, bursty traffic, or uncontrolled Denial of Service attacks. \"Some peers aren\'t as responsive to upgrading their peering infrastructure, nor are they of similar mind with respect for the desire for peering bandwidth headroom[1].\" The large gradations of public peering bandwidth help reconcile these two issues. 2. Ease of administration a. Public peering is the easiest and fastest way to both turn up and turn down a peering sessions, since no physical work is required. Peering is soft configured by the two parties on the router and the peering session is up. b. It is common for a network to set up a trial peering session to determine the amount of traffic that would be exchanged should a session be turned up. If there is public peering capacity available, there is no incremental cost or extra administrative work required to turn up a trial peer, and the information gathered may prevent choosing an incorrect private peering port size if the traffic is moved to a private peer later. c. Many Peering Coordinators must work within a budget, and do not have decision making authority for purchases within their company. Once the public peering switch port is ordered, there is no additional cost and therefore no additional hurdle to peering for the Peering Coordinator. d. Public Peering provides financial predictability. The hardware requirements and monthly recurring costs of peering are the same every month[2]. This makes planning and budgeting much easier. e. 10 Public Peering scales large peering sessions (those greater than 1Gbps) seamlessly, while private peering beyond gigE capacities requires private peering at 10G (very expensive), or connecting multiple gigEs together, which can be tricky[3]. 3. Public Peering is used as Selection Criteria by Customers a. Corporate and Enterprise customers continue to ask to see the list of the ISP\'s public peering points[4]. 4. Public Peering May Be the only Cost Effective way to Peer across multiple Colos a. Across Europe, where public peering across multiple collocation centers is the norm, private peering is often a much more expensive solution. Purchasing private peering circuits within a metro is potentially very expensive, while the same traffic can traverse a shared peering fabric for much less. The Top 5 Reasons Private Peering is better than Public Peering --------------------------------------------------------------------------------------------- Here are the strongest argument private peering advocates shared with the author. 1. Private Peering Sessions are Easier to Monitor a. SNMP Counters can be easily collected on each peering port to monitor the utilization of the Peering Session resources. No time intensive Netflow or expensive network analysis software[5] is required to sort through shared peering fabric data to determine per-peering-session traffic volume. b. Greater Visibility: No Blind Oversubscription Problem. With public peering, the remote peer could be congesting his port with the other peering sessions and you have no visibility into their public peering port utilization. Packets could be dropped due to port oversubscription resulting in poor peering performance. Since Private Peering involves only the two parties, when the port reaches an agreed upon utilization (say 60% utilization for example), both parties can see that it is time to upgrade the peering session. 2. Private Peering is Very Cost Effective a. If an expected peering port and cross connect costs were \$400 per month and the parties expected to send 40Mbps to each other, the EPPR would be \$400/40Mbps=$10/Mbps, a very attractive price in today\'s transit market. b. For those who exchange traffic with a few large peers, the 80%/20% rule applies; the majority of peering benefits can be derived by peering with the 20% of potential peers that deliver 80% of your traffic. This suggests fewer larger peers is preferable over picking up lots of small peers across a public peering fabric. 3. Private Peering is more reliable and easier to debug. a. Private Peering involves fewer network components that could break.[6] It should be noted that this argument weakens when the \"private\" peering are provisioned across VLANs, though optical interconnects, telco provisioned SONET services, or other active electronics. b. An architecture of private peering removes the variability of support processes across IXes[7]. Across Europe, each IX is different, and a NOC Operator may need to understand the processes, the levels of support and debugging capabilities of the switch support staff on call at the IX, and may even need to craft NOC scripts to navigate through the IX operations tasks. A private peering architecture provides consistency that helps the NOC debug and fix things more rapidly. c. The greater fear is that layer 2 fabrics could be connected through other layer two fabrics perhaps without the knowledge or consent of the peer, resulting in a very difficult debugging and diagnostics situation if a peering failure occurs. 4. Private Peering Sessions are More Secure a. A private peering network that is directly connected only with those with whom there is an explicit peering arrangement is more secure than a network that connects to a public peering fabric that includes participants with whom there is no relationship with the company. There is some history here; early exchange points were places where \"traffic stealing\" was accomplished by pointing default at an unsuspecting and poorly secured public peer. Other problems included peers tunneling traffic across the ocean across a peer\'s network. These things are explicitly disallowed in most peering and IX terms and conditions and can be further secured through filtering, but are still seen as potential hazards minimized by privately peering. b. An architecture that solely privately peers is less likely to be compromised. Since fiber has no active components that can be administered, there is nothing that can be broken into. With a switch or other active electronics in between peers, there is the possibility that traffic can be captured at the peering point without their detection. It is relatively easy to mirror a public peering port as compared with tapping into private peering fiber cross connects without the detection of the peers involved. A few ISPs pointed to technology that can passively tap into fiber interconnects, which if true, would decrease the strength of this argument. 5. Private Peering Inclination Signals a More Attractive Peer. a. The \"Big Players\" privately peer with each other and some even loath Public Peering Fabrics for historical reasons. Adopting this attitude puts one in the company of the largest Tier 1 ISPs in the world. \"For certain very large networks, public peering makes no sense at all. For certain very small networks, public peering may make perfect sense[8].\" Or put more harshly, \"if you think that public peering is a good idea, you\'re just not large enough yet[9].\" ________________________________ [1] James Rice (LoNap), formerly engineering for BBC Internet. [2] Modulo the incremental costs for hardware at the cost steps described earlier and the pricing increases at the end of contract terms with the IX Operator. It was pointed out during conversations at the RIPE 50 meeting that the LINX charges a metered rate beyond the flat peering fee, and that some IXes have a fractional gigabit Ethernet rate that causes pricing steps. [3] Patrick Gilmore (Akamai) in conversation 4/7/2005 regarding load balancing across multiple cross connects. [4] Frank Orlowski (T-Systems) in conversation 4/8/2005. [5] Some of these tools cost \$50,000 to license! [6] Remco Donker (MCI) and Nina Hjorth Bargiser (Tele Danmark) point out that some people view large capacity public peering as too risky; losing a single large public peering port would cause massive disruption to the infrastructure, and would result in much larger convergence times than if a single private peering port went out. [7] Falk Bornstaedt and Frank Orlowski (T-Systems). [8] Richard Steenbergen conversation 3/23/2005 [9] Anonymous Bill\'s Minutes From the Meeting From [email protected] Fri May 20 09:36:37 2005 Date: Thu, 19 May 2005 11:53:04 -0700 From: William B. Norton Reply-To: [email protected] To: [email protected] Cc: [email protected] Subject: Peering BOF IX Meeting Minutes Peering BOF IX Meeting Minutes Seattle, WA May 16, 2005 7:30-9:00PM ...Transcribing my notes here for those who couldn\'t make the Peering BOF... comments/corrections to [email protected] or [email protected] A 5 Minute Plea for Multicast Peering ------------------------------------------------- Celeste Anderson (ISI/Los Nettos) spoke about the need for greater peering of native multicast routing. The audience commented that the volume of multicast traffic was still relatively small (a few T1\'s worth) in comparison to unicast traffic, and that there is still not significant customer demand to do so. We discussed the chicken and egg problems for a bit. Transit Survey ------------------------ A few people in the community suggested it would be good to get a sense of transit prices, to see if they were continuing to fall, remaining constant, or were rising back up. In previous white papers I had polled the Peering Coordinator Community to get a sense of transit prices for comparison against peering costs, so with this previous data and an audience survey we to take a stab. I asserted that with transit you often get what you pay for, and we were not interested in identifying the \"lowest price\", the \"bottom feeder\" price points that have no customer service, and that there is in fact a qualitative difference between transit services. I was looking for approximations of \"Tier 1 ISP\" pricing – as expected, there was some debate here. To avoid the rathole of \"Tier 1\" etc. and to focus on \"quality\" of transit services for a quick price measure I pulled together some questions to disqualify some upstream providers from the survey: Q1: When you complain about packet loss to your Upstream, you are told A) I have Bob working on it, he will call you back in 15 minutes B) Call this other number (which rings busy) C) …Let me put you on hold for an hour(Barry Manilow sings the songs that make the whole world sing) D) You should have sent your packets earlier I told folks if they answered \"C\" or \"D\" to please not answer the poll – we were not interested in bottom feeder pricing for this poll. Q2: My Upstream Provider\'s Reliability is A) 6 9\'s B) Close to 6 9\'s C) Closer to 9 6\'s D) Don\'t know – I\'ll let you know when they stay up long enough to measure. I told folks if they answered \"C\" or \"D\" to please not answer the poll– we were not interested in bottom feeder pricing for this poll. Q3: My Upstream Provider\'s Customer Service Makes Me Feel… A) Like a VIP B) Like a Nuisance C) Very, very unclean. D) Like I was just traded to another inmate for 2 packs of menthol cigarettes. I told folks if they answered \"C\" or \"D\" to please not answer the poll– we were not interested in bottom feeder pricing for this poll. Source: A couple of these questions/answers came from a Wired magazine article I read on the flight up, which referenced http://www.5ives.com. While not a particularly scientific survey, we did get 28 viable data points with the averages being: 10Mbps commit: $41.75/Mbps 100Mbps commit: $33.83/Mbps 1000Mbps commit: \$20.73/Mbps 10000Mbps commit: \$13.80/Mbps About 6 months or so ago I did a similar poll with the Peering Coordinator Community and the #s were around \$85, \$60, \$45, \$30, indicating that perhaps the transit prices have indeed fallen. If any of you are interested in the raw data (thanks to Eric Troyer for putting the data points into a spreadsheet) let me know and I\'ll email you the spreadsheet. Peering at 10G – introduction to The Great (Public vs. Private) Peering Debate ---------------------------------------------------------------------------------------------------------------- The motivation for the Great Debate was a white paper I am working on called \"The Great (Public vs. Private) Peering Debate: Peering at 10G\" in which I documented the Peering Coordinator Community assertion and the math that the next best alternative to 10G Public Peering was many 1G Private Peering sessions. I walked through the models for both cases (10G Public and 1G Private) peering, specifying sample equipment (thanks ras!), cost estimates, etc. so we could compare the two alternatives side-by-side. There were many valid points raised during this discussion including: 1) In the modeling we were not including backbone costs, only IX and Peering equipment fees at one location, 2) There are other valid configurations of equipment, including removing the peering router and using switches by themselves (debate here as well), 3) There were a wide variety of redundancy configurations that could/should be considered as well in both cases. The nice thing about modeling this stuff is the ability to identify and discuss assumptions, to change #\'s, to have something on the table to discuss, and it was a lively discussion before and after the BOF. The punch line for the current model I shared was that public peering at 10G and private peering at 1G both are very cost effective solutions, yielding less than \$10/Mbps with a few gigabits of peering. Also, the more traffic peered, the more the cost of these two models of peering converged – so Public vs. Private becomes an architectural / religious issue. This leads to the Great Debate – when do people prefer Public Peering and when do they prefer Private Peering, and why? The Great (Public vs. Private) Peering Debate ------------------------------------------------------------------- I recruited Maurice Dean (who was the Peering Coordinator at Global Crossing and now at Google) to present and defend \"The Strongest Arguments for Public Peering\", and Peter Cohen (Peering Coordinator for Telia) to share \"The Strongest Arguments for Private Peering\". We used a modified Oxford Style Debate, providing each side three minutes for opening remarks, three minutes each to attack the other side\'s points and defend their own, a few minutes for the audience to ask clarification questions, and finally two minutes for the debaters to present summary remarks. The audience would then vote for \"Who made the more compelling case.\" Maurice started out by pointing out that IXes today are not the IXEs of 1995, but rather are large and reliable infrastructure that provide access to a rich population of potential peers. Public peering provides instantaneous access to peers, provides aggregation benefits, ease of administration and is easy to scale peering capacity. He pointed also to the marketing benefits of public peering at the IXes. Peter opened by stating that Private Peering provided superior control over peering infrastructure. He went on that Private Peering scaled very well, that the same fiber pairs could be reused as both sides simply upgraded cards. Private Peering is simpler according to Peter since no NetFlow was needed, that there were not 20 peers all peering across the same 10G interface. For some he claimed ISPs, the only way to measure public peering traffic volume to a peer was to turn down a peering session and see the difference in traffic load. Maurice countered reinforcing that modern IXes have overcome the head of line blocking issues of the past and indeed scale very well, and in fact scale well even across a metro area. He defended the NetFlow attack by mentioning that some IXes have sFlow, providing public peering visibility on a per-peer traffic volume basis. Peter countered that Maurice was a \"Stooly for the IXes\", and depending on a single port for peering is asking for trouble. Further, participation in some IXes requires going to member meetings, and who has time for that. Finally that the added complexity of adding a public peering switch was problematic – he used the analogy of air travel. \"How many of you prefer a direct flight over one with connections?\" The audience asked a variety of questions next but I did not jot them all down. A few points did come up though – that circuit upgrades for private peering can take 6 months or more depending on which side is in a hurry to upgrade. Another point was that public peering was seen by some as easier to justify to their company since it would be used across many peers. The closing remarks were a rehash of the points above, but Maurice introduced a couple additional points – that 90 day trials could be effectively done over a public peering fabric without additional costs to those attached, and that public peering fabrics enabled more opportunities (for peering? For add\'l services? For transit sales?...not sure what he meant here). Peter reasserted that placing all the eggs in one public peering port was just asking for trouble. The audience next voted \"Who presented the more compelling case?\" We had to count twice because it was so close. The final results: Public Peering presented the more compelling case: 37 Private Peering presented the more compelling case: 33 Maurice Dean won the Great Peering Debate. White Paper Available -------------------------------- I captured these and other arguments for and against private peering in the white paper mentioned above – I would love to have a few more reviewers give me some feedback/edits/etc. If you are interested in 10 Gigabit Ethernet Peering or the debate discussion, send me an email ([email protected]) with the Subject: \"The Great (Public vs. Private) Peering Debate – Peering at 10G\" and I\'ll send you a copy. If you provide comments on the draft I will add you to the acknowledgements section of the next version of the document. We were running out of time so we moved quickly to Peering Personals, giving Peering Coordinators a chance to introduce themselves to the group. Peering Personals – (jotted down everything on the sheets) -------------------------------------------------------------------------------------- Korea Telecom – 4766 – Bong-Hwa Song – 40 Gbps Capacity, peering in Seattle PAIX, Palo Alto PAIX, EQLA, LINX, AMSIX, [email protected] AARNET – 7575 – Mark Prior – Research Net, Seattle SIX, PAIX, LAIIX, LAAP, FixW, P|Wave, [email protected] Netflix – Vish Y – [email protected] – Selective peer Steve Gibbard – PCH – 42, 3856 – Data Collection – Open Peering 0 25 locations all over the world (SIX, EQLA, LAIIX, NYIIX, PAIXNY, EQASH,NOTA,…) Steve Gibbard – Hurricane Electric – 6939 – [email protected], [email protected] – 2700 routes, public but migrating to private at EQSJO, EQLA, EQCHI, EQDAL, EQASH, PAIXPA,NYIIX, LINX, AMSIX Brokaw Price – Yahoo! – 10310 – OPEN – [email protected] Todd Underwood – 64597 – [email protected] – NOTA, LINX, Goofy peering, route collection only, store updates, Google – Maurice Dean – 15169 – selective peering – [email protected], NYIIX, EQ-CHI, EQCHI, EQASH, NOTA, PAIXPA,PAIXVA,1118th, TelX (60 Hudson)., LINX< AMSIX, LAIIX Akamai – 12222 – Patrick Gilmore – 20940 outside U.S., OPEN and at every IX, content heavy, [email protected]i.com ESNET – 293 – Yvonne – ipv4, ipv6, multicast, EQASH, EQSJO, MAEEast MAEWest, PAIX, AADS, FixW, Pacific NW Gigapop, [email protected], selective peering policy with AUP Celeste Anderson – AS4, AS27, AS2152/2153, ISI/Los Nettos, research net, lots of eyeballs, LAIIX, LAAP, Pacific Wave, PAIX LA, Mostly OPEN~selective, eyeballs, [email protected], [email protected], Matt Peterson – SixApart , AS# pending, SIX, EQSJO, LiveJournal.com, [email protected] -------------------------------------------------------------------------------------------------------------- Hope this help!

    View full abstract page.
    Moderators:
    • Bill Norton, Equinix.
    9:00pm - 10:30pmCascade II<BR>Mezzanine Level

    ISP Security and NSP-SEC BOF IX

    Our agenda includes: <UL> <LI> Bill Manning - Pharming: demonstrated and tools to detect such an attack <BR><BR></LI> <LI> Rodney Joffe - A DDoS cloud and a seperated command and control path <BR><BR></LI> <LI> Darrel Lewis - Filtering port 53, dangers? <BR><BR></LI> </UL>

    View full abstract page.
    Moderators:
    • Chris Morrow, UUNET.
    Tuesday, May 17 2005
    Time/Webcast:Room:Topic/Abstract:Presenter/Sponsor:Presentation Files:
    8:00am - 9:00amGrand Foyer<BR>Grand LevelContinental Breakfast
    9:00am - 9:30amGrand Ballroom II-III<BR>Grand Level

    IPv6 - Evolutionary Issues and Challenges

    Over the last nine months, Cable & Wireless has rolled out native IPv6 across the whole of the AS1273 backbone. Today, several large customers are using this service. This presentation covers the basic design, the practical experience gained during this rollout, as well as the challenges that needed to be overcome. It provides a collection of useful tips to anyone wanting to roll out production quality native IPv6 services on a global backbone. The rollout also brought to light several issues with the present ad hoc deployment of v6 by the Internet Community at large, and, despite the protocol\'s age/maturity, the general lack of vendor support. This presentation is therefore also a plea directed at vendors and the Internet community alike to clean up its IPv6 story and support its use in production environments.

    View full abstract page.
    Speakers:

    • Udo Steinegger, Cable & Wireless
    • Udo Steinegger has been working in the Cable & Wireless IP Engineering Group since 2000. He is responsible for designing C&W\'s public IP network and portions of C&W\'s MPLS VPN network. Udo\'s interests focus on MPLS-based technologies (L2/L3 VPNs, carrier-to-carrier interconnections, QoS, etc.), IPv6, and extending/operating C&W\'s IXP (INXS).
    youtubeIPv6 - Evolutionary Issues and Challenges
    pdfUdo Steinegger Presentation(PDF)
    9:30am - 9:50amGrand Ballroom II-III<BR>Grand Level

    Inter-AS Traffic Engineering Case Studies as Requirements for IPv6 Multihoming Solutions

    Much work is being done to provide an IPv6 multihoming solution that doesn\'t depend on deaggergation. While the draft solutions take into consideration failover and load sharing, they fail to support some of the commonly used inter-AS traffic engineering functions. The presentation is an attempt to provide the three basic inter-AS traffic engineering approaches as a clear example of IPv6 multihoming requirements.

    View full abstract page.
    Speakers:

    • Jason Schiller, UUNET
    • Jason Schiller is a Senior Internet Network Engineer in the IP Network Engineering Department at UUNET / MCI. He has been with the company for over seven years. His current role includes designing, evaluating, and qualifying networks for deployment in UUNET\'s backbone for the Americas region. Jason also completes field trials and acts as highest level of escalation for issues in the Americas continental networks and for multicast issues globally. He is also responsible for defining and maintaining global standards for each of the continental UUNET networks. Previous projects include designing the UUCast multicast network and the Latin American network. Current interests include Internet routing, multicast, and IPv6.
    youtubeInter-AS Traffic Engineering Case Studies as Requirements for IPv6 Multihoming Solutions
    pdfJason Schiller Presentation(PDF)
    9:50am - 10:05amGrand Ballroom II-III<BR>Grand Level

    Moonv6 Update

    This talk is intended to provide an update to the community on the MoonV6 effort covering IPv6 interoperability testing.

    View full abstract page.
    Speakers:
    • Scott Gross, MCI.
    youtubeMoonv6 Update
    pdfScott Gross Presentation(PDF)
    10:05am - 10:35amGrand Ballroom II-III<BR>Grand Level

    Internet Mini-Cores: Local Communications in the Internet\'s \"Spur\" Regions

    The Internet currently consists of a well connected core and less well connected spurs. Within the core, connectivity is good. For the rest of the world, areas that relate to the core as long spurs, its a different story. Many different ISPs in these regions have connectivity to the core, but few connect to each other. The connections to the core often extend long distances, sometimes over satellite links. Even local connectivity uses these connections, so data may have to go half way around the world and back in order to go a few miles, leading to great expense and poor performance. While true local communications are vulnerable mainly to problems with fiber links of a few miles, long distance communications are vulnerable to failures of microwave and satellite links going long distances. When local communications are carried on long distance connections, local communications become vulnerable to the reliability problems of long distance circuits. The purpose of this talk is to examine the problems this structure causes for the spur regions of the Internet, and to propose some solutions.

    View full abstract page.
    Speakers:

    • Steve Gibbard, PCH
    • Steve Gibbard is the Network Architect at Packet Clearing House. He runs a global research network and an anycast DNS network that hosts the top level domains for several countries as well as a root DNS server, and studies the interconnection of Internet networks around the world. In addition, Steve carries out network architecture and peering work as a consultant for several ISPs. He is a former Senior Network Engineer at Cable & Wireless, and has held network engineering positions at Digital Island and World Wide Net.
    youtubeInternet Mini-Cores: Local Communications in the Internet's "Spur" Regions
    pdfSteve Gibbard Presentation(PDF)
    10:35am - 11:05amGrand Ballroom II-III<BR>Grand Level

    Network-Wide Inter-Domain Routing Policies: Design and Realization

    Currently the inter-domain routing policy of an autonomous system is often ill-specified, undergoes constant adjustments for reasons of traffic engineering and/or to address-specific customer wishes, and is often realized by manually configuring each router individually, an error-prone approach. This talk discusses a system that raises the abstraction level at which routing policies are specified from individual BGP statements to a network-wide routing policy. <BR><BR> Our system enables an autonomous system to: <OL> <LI> explicitly specify its inter-domain network-wide routing policy as first class entities, an extensible collection of individual policies and services such as a peering-policy, a filter-martians-policy, a signaled black-hole service, etc.; <BR><BR></LI> <LI> specify its routing policy independently of the current state of the network; <BR><BR></LI> <LI> automatically generate the appropriate pieces of the router configurations for all routers, including various vendors, in the network from appropriate databases; <BR><BR></LI> <LI> automatically generate a documentation of the current active routing policy in RPSL; <BR><BR></LI> <LI> enable customers of the AS to apply changes to the route-sets they announce without any explicit human-to-human interaction. <BR><BR></LI> </OL> We are now able to manage the overall routing architecture rather than each individual router. Initial deployment of the system to manage the network-wide routing policy of Deutsche Telekom affirms the above advantages in an operational setting.

    View full abstract page.
    Speakers:
    • Hagen Boehm, Deutsche Telekom.
    • Anja Feldmann, Technical University Munich
    • Anja Feldmann is currently a professor of network architectures in the Computer Science department at the Technische Universitaet Muenchen, Germany. From 2000 to 2002 she was a professor of computer networking at Saarland University, Germany. Before that (1995 to 1999), Anja was a member of the Networking and Distributed Systems Center at AT&T Labs -- Research in Florham Park, New Jersey. Her current research interests include Internet measurement, traffic engineering and traffic characterization, network performance debugging, and intrusion detection. She received an M.S. degree in Computer Science from the University of Paderborn, Paderborn, Germany, in 1990, and M.S. and Ph.D. degrees in Computer Science from Carnegie Mellon University in Pittsburgh, USA, in 1991 and 1995, respectively.
    • Olaf Maennel, Technical University Munich.
    • Christian Reiser, Technical University Munich.
    • Ruediger Volk, Deutsche Telekom.
    pdfAnja Feldmann Presentation(PDF)
    youtubeNetwork-Wide Inter-Domain Routing Policies: Design and Realization
    11:05am - 11:30amGrand FoyerBreak
    11:30am - 11:50amGrand Ballroom II-III<BR>Grand Level

    Beyond 10 Gigabit Ethernet

    What is next for Ethernet? Vendors are starting to develop new technologies such as 40 GbE and 100 GbE. We\'re at the point in the industry where operators need to support vendors and build critical mass as the IEEE starts to put out Call for Interests on these technologies. The pros and cons of 40 GbE and 100 GbE are presented, followed by details on what the next steps are for each technology, and how operators can get involved to drive the standards.

    View full abstract page.
    Speakers:

    • Subramanian Krishnamurthy, Force10
    • Subi Krishnamurthy is Director of Technology at Force10 Networks, and has 15 years of experience in silicon design and development. Previously, he was an ASIC Manager in the hardware engineering group and developed three generations of lookup systems for Force10\'s 10 GbE switch/router platform. At his previous company, Rendition Inc., Subi developed 3D graphics processors for PCs. He holds a B.E. in Computer Engineering from Regional Engineering College, Trichy, India, and an M.S. in Computer Science from Southern Illinois University, Carbondale.
    youtubeBeyond 10 Gigabit Ethernet
    pdfSubramanian Krishnamurthy Presentation(PDF)
    11:50am - 12:50pmGrand Ballroom II-III<BR>Grand LevelInternet Exchange Operator PanelModerators:

    • Chris Malayter, TDS Telecom
    • Chris Malayter is a Data Network Engineer at TDS Telecom in Madison, WI. He has held a number of roles at TDS. In his current position, Chris is responsible for designing and engineering the data networks that comprise TDS\' Internet business. Chris was a primary player in the recent redesign of the TDS nationwide core network. In addition, he is responsible for all Internet peering activities at TDS Telecom.
    Panelists:
    • Celeste Anderson, Pacific Wave.
    • Tom Bechly, MCI/MAE.
    • Troy Davis, SIX.
    • Mike Hughes, LINX.
    • Dave Meyer, OregonIX.
    pdfChris Malayter Presentation(PDF)
    youtubeInternet Exchange Operator Panel
    12:50pm - 1:00pmGrand Ballroom II-III<BR>Grand LevelClosing CommentsSpeakers:
    • Mike McPherson, Merit Network.
    youtubeClosing Comments
    2:30pm - 5:00pmCascade II<BR>Mezzanine Level

    Community Meeting III

    Tuesday afternoon and evening: Community Dialog On Tuesday afternoon we\'ll work together to resolve open issues remaining from Sunday evening. By Tuesday evening, we\'ll be ready to prepare an action plan for next steps to take in the continuing evolution of NANOG. <HR> <B>Steve Gibbard\'s notes from Tuesday\'s meeting</B><BR> From: Steve Gibbard <BR> Subject: Notes from today\'s NANOG \"community meeting\" <BR><BR> Merit had many hours scheduled for discussions on the future of NANOG today. After less than 45 minutes, we agreed to all \"declare victory and enjoy a beautiful afternoon.\" <BR><BR> Mike McPherson, Merit\'s President, presented Merit\'s draft of the NANOG bylaw proposal. Merit\'s draft is quite similar to my version of the NANOG Reform bylaw proposal presented on these lists a few weeks ago, being the same word for word in some places with some differences in others. <BR><BR> Merit invited Steve Feldman, the program committee chair, and Marty Hannigan, who they had somehow decided was a representative of the NANOG Reform group, to comment on it. Steve said the program committee was willing to accept the proposal and that he was glad Merit was now thinking about what NANOG should be. Marty disclaimed representation of the NANOG Reform group (rightly -- he wasn\'t part of the NANOG Reform proposals), but said he agreed with Merit\'s proposal too. <BR><BR> As the most recent editor of the NANOG Reform bylaws, I thanked Merit for their proposal, and said I thought it was an improvement over by own. <BR><BR> Various others expressed support for the Merit proposal. <BR><BR> Mitchell Rose expressed a concern that the summary of the Merit proposal on the slides referenced NANOG as an organization for Internet service providers, and appeared to be excluding other large network operators. Merit agreed that this could be changed, but it appears that was wording only in the Powerpoint summary and not in their actual draft. <BR><BR> Vijay Gill said we\'re all crazy and should just go back to how things were. Nobody seemed willing to publicly agree with him. <BR><BR> Daniel Karrenberg suggested that since we all seemed to be agreeing with each other, we should \"declare victory and go home.\" There seemed to be general agreement with that. <BR><BR> So, it looks like we\'ll end up with the Merit draft or something pretty close to that, which I think is the right outcome. We should have \"steering committee\" elections sometime this summer, with the committee in place in time for the fall NANOG. I told Susan Harris that I\'d be happy to help with wording as they finalize it. She seemed receptive to that idea. -Steve

    View full abstract page.
    Speakers:
    • Betty Burke, Merit Network.
    • Steve Feldman, CNET.
    • Martin Hannigan, VeriSign.
    • Marcia Mardis, Merit Network.
    youtubeCommunity Meeting III
    5:00pm - 7:00pm DinnerSpeakers:
    • On Your Own, None.
    7:00pm - 8:00pmCascade II<BR>Mezzanine LevelCommunity Meeting IVModerators:
    • Betty Burke, Merit Network.

     

    ^ Back to Top