- NANOG - lists.nanog.org

Re: Quarantine your infected users spreading malware
by Scott Weeks 20 Feb '06

20 Feb '06

> > Oh geez, here we go again... Search the archives and > > read until you're content. It's a non-thread. This > > horse isn't only dead, it's not even a grease spot on > > the road any more. :-( > > I quite agree, which is why I trived to cover the > philosophical part from both sides. Now, how about some > solutions that came about since our last discussion that > was nothing BUT philosophy? You can't get there from here. scott

2 1

Cisco 3550 replacement
by Jacky Lam 20 Feb '06

20 Feb '06

Hi all, I'm currently looking for a CPE that can replace the Cisco 3550 we currently deploy in our network. Key features that I'm looking for are as follows: Hierarchical QOS Traffic shaping/policing L3VPN functionality(VRF-lite) BGP OSPF dot1q some sort of spanning tree Any help would be really appreciated, Jacky

3 3

RE: MLPPP over MPLS
by Peering 20 Feb '06

20 Feb '06

I've been told by Juniper that the MTU negotiation problem was fixed in the 7.x versions. We're upgrading soon, so I hope to find out for myself. Diane Turley Sr. Network Engineer Xspedius Communications Co. 636-625-7178 -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Brent A O'Keeffe Sent: Monday, February 20, 2006 7:57 AM To: Jon Lewis Cc: Jon R. Kibler; nanog(a)merit.net Subject: Re: MLPPP over MPLS It may also be worth noting that if the provider is running Juniper and not Cisco, there are fragmentation issues with certain versions of Juniper code. The MLPPP session cannot agree on an MTU and usually stop somewhere around 100 bytes if they do. The workaround is to implement "ppp multilink fragment disable" on the Cisco Multilink interface. Brent Jon Lewis <jlewis(a)lewis.org> Sent by: owner-nanog(a)merit.edu 02/17/2006 03:38 PM To "Jon R. Kibler" <Jon.Kibler(a)aset.com> cc nanog(a)merit.net Subject Re: MLPPP over MPLS On Fri, 17 Feb 2006, Jon R. Kibler wrote: > We have a customer that is implementing an MPLS network that will have 2 > to 6 T1 feeds at some locations that will be using MLPPP for channel > bonding. This is a telco provided network that will be customer managed. It's not clear from your message, but I'm assuming the MLPPP will be from PE to CE and that the MPLS you speak of is MPLS VPN. If that's the case, on the customer end, it's just a MLPPP, and on your end, it's an MLPPP with an "ip vrf forwarding foo" statement. It's probably more than the average CCNA can handle (but so are MLPPP, MPLS, and most day to day IOS config work). Anyone who actually uses IOS on a regular basis (as opposed to someone who crammed for an exam and knows squat) should have no trouble with it. > The customer is being told by their router vendor that an MLPPP/MPLS > network is 'too complex' to be managed by anyone except for the router > vendor's VARs or the telco. They indicated that it would be impossible > for the customer's router vendor certified network person to come up to > speed on MLPPP/MPLS configurations and manage such a network -- that it > takes years to adequately learn how to manage that type of network > configuration. I think someone may be confusing "providing MPLS service" with "buying MPLS service". A customer buying MPLS VPN service never sees any of the MPLS tags or messes with MPLS/tag-switching commands. There is no added complexity...or at least there doesn't need to be any. > ================================================== > Filtered by: TRUSTEM.COM's Email Filtering Service > http://www.trustem.com/ > No Spam. No Viruses. Just Good Clean Email. Virus-free, because I say it is...and I run Pine on Linux :) ---------------------------------------------------------------------- Jon Lewis | I route Senior Network Engineer | therefore you are Atlantic Net | _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________

1 0

[operational update] Fast-Flux (fast IP changing hosts)
by Gadi Evron 19 Feb '06

19 Feb '06

[X-posted] I figure it's a good idea to update the ops community on a new term called Fast-Flux.. but for that you need a bit of background. There have been three *main* new phishing tricks used over the past year.. which will bring us to what interests us... POST information in the mail message ------------------------------------ That means that the user fills his or her data in the HTML email message itself, which then sends the information to a legit-looking site. The problem with that, is how do you convince an ISP that a real (compromised) site is indeed a phishing site, if there is no phishy-looking page there, but rather a script hiding somewhere? Trojan horses ------------- This is an increasing problem. People get infected with these bots, zombies or whatever else you'd like to call them and then start sending out the phishing spam, while alternating the IP address of the phishing server. Now.. Which brings us to... Fast-Flux --------- Fast Flux is a term coined in the anti spam world to describe such Trojan horses' activity. The DNS RR leading to the phishing server keeps changing, with a new IP address (or 10) every 10 minutes to a day. Trying to keep up and eliminate these sites before they move again is frustrating and problematic, making the bottle-neck the DNS RR which needs to be nuked. At times this is even on the domain level itself, making termination/suspension of the domain critical. This has been seen before, but before this past year mostly in POC's. This is mostly known is closed communities, and needs some public light. A lot more data and test cases out there, but I figure this is enough for now.. Gadi. -- http://blogs.securiteam.com/ "Out of the box is where I live". -- Cara "Starbuck" Thrace, Battlestar Galactica.

1 0

NANOG36-NOTES 2006.02.14 Tools BOF Notes
by Matthew Petach 18 Feb '06

18 Feb '06

Last notes of the day... Matt 2006.02.14 Tools BOF Todd Underwood, panel moderator A number of interesting tools presented earlier today; all of them are good and interesting and solve a particular set of problems. None are in widespread use. There's a lot of possible reasons; do they solve problems you don't have, in which case they can move onto something new; or they solve a problem similar to one you have, but not quite. Or they solve a problem you can't quite implement yet. Discuss use cases, problems they're trying to solve, and give feedback, as interactively as comfortably as people can. 3 tools, OpenBGPD, IRR powertools/webtools (to get feedback and is the IRR even useful anymore?) and Flamingo as one of 2 netflow platforms. Start with Henning, active in open source software development; he'll go in more depth on openbgpd. OpenBGPD Henning Brauer henning at openbsd.org 3 process design Principle of least privilege the RDE (route decision engine) does not need any special priv at all, so it runs as __bgpd:__bgpd: chrooted to /var/empty SE needs to bind to TCP/179 parent needs to modify kernel routing table. Session Engine (SE) needs to bind to 179/tcp we have the parent open sockets see recvmsg(2) parent needsd to keep track of which fds the SE has open, so it doesn't bind() again to same ip/port the SE can drop all privs, then. SE 2 since one process handles all bgpd, need nonblocking sockets. on blocking, you call write(2), won't reurn until it's done or get errors on nonblocking, returns as soon as it can't proceed immediately So, have to handle buffer managmeent SE 3 designed an easy to use buffer API and mesg handling system. Messaging internal messaging is core comp. in reused for OpenNTPD, OPenOSPFD, and somee more. bgpd has more than 52 message types, more than OpenSSH bgpctl talks to bgpd using same imsg socket tcp md5 some very old code in kernel for tcp md5, from 4.4 BSD never worked tcp md5 is somewhat similar to ipsec, ah, so implement it within IPSec maze. Had to add pfkey interface to bgpd; committee designed API. that made IPSec that much easier; extended the API so they can request unused SPIs from kernel, don't have to be configured manually. tcp md5/ipsec when you don't have tcp md5 or ipsec in place, big tcp windows are risky stay at 16k window unless you have tcp md5 or ipsec, then you get 64K so ipsec improves performance. Joel Yagli asks how big a tcp window do you need for a BGP session at all? initial connection gets faster with 64K, but thereafter, similar. looking glass just added an optional second control socket that is restricted to the "show" operations regular bgpctl binary can be used with it cgi, yeah, that needs to be hacked in shape, but it's easy. Juniper only does static IPSec setup, so requires nasty setup. OpenBGPD is dynamic, but interoperates with Junipers. So back to looking glass, security on OpenBSD, the httpd (an apache 1.3 variant) runs in a chroot jail by default th readonly socket can be placed inside that jail bgpd_flags="-r /var/www/bgpd.rsock" in rc.conf.local put a statically linked bgpctl binary in the chroot /path/to/bgpctl -s /bgp.rsock, $ impressions from road to ipv6 most heinous checkin message yet. The lower 2 bytes of the scopeID overwrite part of the v6 address...ugly! Performance http://hasso.linux.ee/linux/openbgpd.php it's quick openBGPD 3.6 port for linux; can't communicate with kernel, no v6, no md5; 8 times faster than quagga. future plans and ideas the biggest task waits outside bgpd itself; kernel routing table. we need to make use of the radix mpath capabilities added in 2004, and add route source markers (BGP, OSPF, etc) bgpd and ospfd can blindly install their routes kernel then knows precedence hard to do, once it's done, routing will be easier. Also need multiple routing tables, with pf acting as table selector so unholy route-to can died, and associated issues vanish/ might be useful with bgpd as well. iddeas for quite radical changs, speed up packet forwarding dramatically. will have fast path where all easy cases can be handled on specialized PCI cards multiple 10GE at wire speed within 2 years. hardware exists, on way to him. for route servers, reversing filter and best path selection would be good. filter generation from RIPE DB or similar but IRR toolset sucks hairy moose balls should be solvable in perl "someone" has to code it. (maybe use IRR power tools for it instead!) [ we can fail over IP addresses already, thanks to CARP we can hve synchronized state tables on multiiple machines, gives HA firewall clusters. Would be really cool to be able to fail over TCP sessions and bgp sessions. could make for BGP hitless failover syncging BGP stuff shouldn't be too hard lots of work, not much time. Money has to come from somewhere, obviously. Unfortunately, people forget about this, just go to mirrors. Vendors don't help Never got anything for OpenSSH yet it comes down to you. yes YOU. buy our CDs, donate cash, tee-shirts, etc. or sponsor events, plane tickets, etc. Matt asks if they can be configured actively only, not binding on port 179. Currently, no. Can bind to loopbacks for the moment, or modify the code as appropriate. RAS asks if they support the lastest IETF draft for collision handling. They don't implement collision detection RFC-wise, no. And they're not active only, without passive. He also asks about comparing a RIB-in; that's been in the code for 2 weeks now, still has some bugs. Add support for passing more than one best path in case people are using this for a looking-glass. ie the VRF style hack for getting multiple views of the same route. Todd asks if they log dump output in MRT format. Short answer, yes. Many thanks to Henning! OK, over to RAS for IRR power tools. One leading question is whether the IRRs are even worthy of supporting, or are they a dead horse we've been flagellating for ten years? Todd kicks it off with question--you developed toolset because you think IRRs are a worthy effort to support, right? RAS notes that manual filters aren't a reasonable means to configure routers. Our current system is broken, something needs to change. Tool was written for internal use initially, Chris Morrow convinced him to release it for others. Not really meant as a plug for the IRRs, it's more "if you're going to use the IRRs Riverdomain, package base, if it can be a .rpm or .deb package, it would help; RAS doesn't do Linux, but others are welcome to package it up. When people go to implement this, they find a lot of cruft lurking around. Verio is the primary forcer right now for using IRRs; Level3 proxy objects are a great pain point. No motivation to remove old information out of the system. Larry Blunt with Merit; if you send email to them, they will remove old stale objects. It may take a little while, but it will get done. They're starting to check for inconsistencies so you can do bulk deletions of blocks that aren't being announced. Could they send out a monthly nag message, send that initially. They charge a yearly fee. When someone doesn't pay, companies will eventually be phased out. About 1600 maintainers, some are proactive about keeping them up to date, others are pretty minimal or are laggards. Website will show out-of-date info, but won't allow cleaning it up; next step is to allow them to clean it up via the web. They're looking to have a simple form vs complex form coming up, for those who don't have a complete understanding of BGP. Report section works across all registries. Could check to see if there's a less specific entry already with a different MAINT-ID. What about an INET-num to block any more specifics from the block from being registered. Challenge centers around the split between IP allocation and route registration. Peter Shoenmaker, works for Verio; many people mirror other databases, so there's compounded stale data. There are certain companies that have large blocks, and they'll register all the more specifics under it as well. Generating those filter lists gets ugly. RAS notes his tool auto-aggregates to least specific block possible. Samantha Billington, ISC, current maintainers of the current IRR ToolSet; would love to re-do it if there were some backing behind it. Currently trying to develop peering tools to make keeping track of peerings more easily. Randy Bush, IIJ, peers at the SIX using a perl script to generate filter lists around peval; it's a decade later, and we're still hacking more tools on top of the same broken data. It's time to do something new; doing the same thing, and expecting different outcome is definition of insanity. He says let's just give up, and change. Todd asks about SBGP/SO-BGP; they haven't caught on, and perhaps never well. But in the meantime, Randy notes it will let you build filters that are at least rigorously verifiable. And it'll be a backend only change in the future to drop in for the IRR in the future. It'll be downhill, incremental work at that point. Randy doesn't think it makes sense to continue forward at all. Let's stop for a year and redo things on better course before another ten years goes past. Randy offers to show Todd his ass...the audience groans, and we return to a more serious note. This is quicksand, let's get out of the quicksand. it's just an issue of going in the wrong direction. If you don't mind doing work twice, OK; but if you do, then save your time and energy, and let's focus on a PKI system. So, let's do PKI now, and we add this into the tools to jump start the process. You get a list of signed objects, you traverse the list of signed attestations that you recieve, you verify up the chain to IANA, and verify that the chain is intact. For Addresses and ASes, IANA is the root. For the identities of the ISPs and RIRs, may not be a single root. IRRs aren't secure enough to use for the database system. It's not transport free? LDAP would very likely be the storage/retrieval system. Let's start coding it; 2585 for queries, it's over HTTP, lets you talk to PKI certificate abstraction. Need to cover changes to certs needed to cover address space and ASNs. Can 2585 cover certificte modification, though? Needs Andy Putnams, Intelliden, config challenge will exist regardless of the pki; how do you ensure that you don't have multiple, overlapping entries? RAS notes that if we could handle PKI inside the IRRR, it would jumpstart the data. Chris asks why we can't start doing verifications with the existing infrastructure? Randy's not saying throw away the existing infrastructure; just pause on chasing it down, and change direction for the future. RPSL is a huge overkill, 90% of it isn't used at all, would we want to put PKI in there? Sandy Murphy, Sparta. Could we use the PKI to prevent people from adding or removing routes that we don't want touched? Could the people RUNNING the IRR check before you stick it in; then we also check on the way out. RFC 2725--her name is on it, but it's really Curtis Villamizer's proposal, but it does allow for the web of trust between systems to start with. Now onto Flamingo; Manish will walk through a live demo off his netflow data. flamingo.merit.edu:4444 it's more for security than traffic engineering; for those of us doing traffic engineering, though might still be of some use. Gives a large overview when we start it up, use the minimum threshold to filter out background noise. Traffic volume based on source AS view is of somewhat interesting. Ooops, neighbor AS, actually. (or origin, depending on your router setting) quad tree works same for AS number, just 16 bit number, not 32 bit archive. collector is based off flow tools, uses similar file format. Can pause updates so you don't loose current data you're about to zoom in on, for example. last view is combined source, dest, port, etc. everything sampled by netflow all in one window. sliders are a little crude, would be nice to have text entry boxes as well as slider bars. You can also list specific networks you care about that you want to see data for. So you can see traffic sourced from a given subnet. Every bar will then be a /32 hostname, will show traffic volumes for each; can shift zoom to limit what is on the display. Can do same visualizations of darknet space. They generate darkspace network off an unnumbered interface, and generating flow data from what is seen on the scatterback. Lots of scans from lots of people. Last 10 seconds or last 2 seconds, very dynamic. so the vertical here is walking across ports. single source port hitting lots of destination ports. Can also playback feeds from netflow collector format, etc. The platform is displaying pretty well at about 5k records/second, but scaling up for for a large content provider would be tough. Most of the code is written in-house, on Linux; may port to other platforms later. Running on a 3.6ghz p4 right now, nice graphics card, 256MB nvidia graphics card, no other real specs right now. Heavy dependencies on openGL, so no licensing for that. Software tool is largely GPL free. Availability is an issue right now. In trials, happy to do more trials, that's where they'll leave it for now. Manpower issues, no QA, no support, so not sure if they can really release it to the public yet. Are there additional visualizations that might help? On the ops side, which of these ways of looking at this would help the poor folks who run NOCs? What about saving profiles the NOC can compare against to recognize quickly "bad things". Mike Hughes (I think) says it's not really a first-alert type tool, it's for a second or third level escalation tool; too hard to interpret for a front line NOC person. They find it most useful for playback, rather than realtime 'spot the attack'. Chris--scaling for netflow is always a challenge. He has 9 routers reporting 50,000 flows/second; he has 300 others to add. So the scaling part is a challenge. The SOC might find it useful. It can use pre-existing netflow/flowtool archive files, server can play those back. Chris Morrow would just like to see some rough stats on what it could support. Mike Hughes, runs layer 2 environment, could it be sFlow and layer 2 aware. Walt Prue asks if he could point at a line to see info about it. On the feature list.

2 1

Exchange Points
by sjk 18 Feb '06

18 Feb '06

We're a small facilities based ISP in Chicago and I am looking for a public exchange point for peering. I have been told, by someone at SBC, that the public NAP here is no longer accepting connections and is essentially going to shut down over time. Has anyone else heard this? Are there other exchange options - other then to haul transport to multiple net operators? Thanks -- Steve

3 2

Disaster recovery using as-prepend?
by Christopher J. Pilkington 18 Feb '06

18 Feb '06

My apologies if this question doesn't belong here. We have a PI /24 we'd like to advertise out of our primary data center for production use. (Well, actually, we'll be advertising a more specific from our /21 assignment, so already not too friendly... but I digress.) We have a disaster recovery site which will have a clone of the myriad production servers. We'd like to fail over to that site automagically. I'm thinking advertising the same prefix and just doing several as-prepends. However, now I'm not sure if this is a polite thing to do or not. Someone mentioned to me something with MEDs, but as soon as that term was used, I started twitching, and couldn't follow the conversation. Would a "good netizen" use the as-prepend method? Or am I missing a simpler/more polite solution? -Christopher

7 10

[operational update] Looking behind the smoke screen of the Internet
by Gadi Evron 18 Feb '06

18 Feb '06

You can find the information and update here: http://blogs.securiteam.com/index.php/archives/298 Apparently nanog drops email messages with long subject lines. Thanks, Gadi. -- http://blogs.securiteam.com/ "Out of the box is where I live". -- Cara "Starbuck" Thrace, Battlestar Galactica.

1 0

RE: MLPPP over MPLS
by Erik Amundson 17 Feb '06

17 Feb '06

I've used MLPPP before with T1s...not the hardest thing to do...in fact, MLFR is a little bigt nastier, but still nothing that the average CCNA couldn't wrap their brain around... Erik Amundson -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On Behalf Of Jon R. Kibler Sent: Friday, February 17, 2006 1:37 PM To: nanog(a)merit.net Subject: MLPPP over MPLS Greetings all, Would anyone who has every done MLPPP over MPLS care to share their experiences with this type of network? We have a customer that is implementing an MPLS network that will have 2 to 6 T1 feeds at some locations that will be using MLPPP for channel bonding. This is a telco provided network that will be customer managed. The routers will be customer managed because the same equipment will have interfaces to another telco's network as a backup to the MPLS network. Needless to say, no telco will support equipment that interfaces competitors networks. The customer is being told by their router vendor that an MLPPP/MPLS network is 'too complex' to be managed by anyone except for the router vendor's VARs or the telco. They indicated that it would be impossible for the customer's router vendor certified network person to come up to speed on MLPPP/MPLS configurations and manage such a network -- that it takes years to adequately learn how to manage that type of network configuration. This doesn't sound like rocket science to me -- it should be simple and rather straight forward, I would think: The telco specifies its requirements for the router configuration, the customer implements that configuration on the required router interfaces, the telco monitors line quality, and the customer does basic router monitoring. Am I missing something here, or is the router vendor just blowing a lot of smoke to try to provide business for some of his clients that provide managed services? Thanks in advance for your feedback! Jon Kibler -- Jon R. Kibler Chief Technical Officer A.S.E.T., Inc. Charleston, SC USA (843) 849-8214 ================================================== Filtered by: TRUSTEM.COM's Email Filtering Service http://www.trustem.com/ No Spam. No Viruses. Just Good Clean Email.

1 0

Peering BOF XI Meeting Minutes ----- D R A F T
by William B. Norton 17 Feb '06

17 Feb '06

Peering BOF XI Meeting Minutes Facilitator: William B. Norton <wbn(a)equinix.com> Agenda 1. Notes from the Field - wbn 2. ad Hoc Transit Survey – Dave Wodelet 3. Paid Peering as an Adjunct to Settlement Free Interconnect (15 min). -wbn 4. The Great Peering Debate (30 min) ras, ianai 5. Peering Contact Database (peeringdb.com) Update (10 min). - ras 6. AS7018 & AS7132 Discussion (15 min) 7. Peering Personals – all (remainder) 1) Notes from the Field Trying something new this NANOG Peering BOF: Community Seating This was a hit! We had 200 chairs arranged in three concentric ovals so everyone could see everyone else. The protocol for speaking did not involve queueing up at a microphone but rather standing up and speaking your peace. It took a little while to get used to it but it certainly facilitated very interactive and lively community discussions. Peering Ecosystems Update – Italy Peering Ecosystem Exception Telecom Italia peers its domestic routes openly in a single (or if needed two) location in Italy. This is counter to every peering ecosystem I have studied; Tier 1 ISPs (those with access to the entire routing table for the country solely via peering relationships) typically will not peer with anyone else, making Telecom Italia and Italy an interesting exception. Daniele (from NaMex) pointed out the recently privatized Telecom Italia peered openly to avoid government regulation, and I mentioned that they also pointed to increased revenue from fiber and copper sales to successful competitive ISPs. Note that this is a different entity from Telecom Italia Sparkle, which is the sole international transit provider for TI and does not peer openly. Job (from AMS-IX) mentioned that KPN is similarly openly peering. - Past Peering Debate documented The last NANOG Peering Ratios debate spilled over into heated discussions in the hallways and I went ahead and documented the strongest arguments overheard on both sides of the issue. I have this white paper available to anyone who wishes to better understand the Peering Ratios issue. This white paper is now freely available. Send email to bill.norton(a)gmail.com with "The Folly of Peering Ratios?" in the subject line and I'll be glad to send a copy of the "The Folly of Peering Ratios?" white paper. 2) Ad Hoc Transit Survey – Dave Wodelet (dave.wodelet(a)sjrb.ca) Dave was interested in continuing the transit survey we have done in the past peering bofs with a little more specificity, so he asked several questions: a) who are your upstream transit providers? b) what are the prices per mbps and commits? c) how old is the contract? d) are there any special aspects of the deal? Dave agreed to report back on the results at the next NANOG Peering BOF. 3) Top 8 reasons Paid Peering Has Not Taken Off The Peering community has discussed paid peering for over a decade. The question was floated around "Why hasn't paid peering taken off?" resulting in the following answers: 1. Unpredictability & Budgeting & Gaming the system 2. We are "peers" & we shouldn't pay. 3. If we pay now it will be harder to migrate to settlement free later 4. No Signatory Authority for $$$ - another group handles vendors/paying 5. Transit Price < Paid Peering Price – why bother, use communities to limit transit, have a backup just in case 6. We don't have that product to offer 7. Low margin product – the margins are already thin on transit, too much effort 8. I don't want to screw up my existing peering relationships. Even if I get some $$, I piss off a peer I care about. This was also a lively discussion resulting in a total of eight reasons when my hallway conversations initially resulted in five reasons why paid peering hasn't taken off. 4) "The Utility of MEDs" Peering Debate • Peering Question: "From a Practical Perspective, are MEDs useful for distributing the peering traffic load?" 2 minutes each: 1. "MEDs are not a useful tool for Peering" - ras 2. "MEDs are a useful tool for Peering" - patrick 3. Ras attacks "MEDs are a useful tool for Peering" position 4. Patrick attacks "MEDs are not a useful tool for Peering" position 5. Closing Arguments • Initial vote: How many people believe MEDs are a useful tool for distributing peering traffic? Group Answer by Vote: MEDs ARE useful. Debate begins... "MEDs are not a useful tool for Peering" - ras 1. MEDs worsen route quality and increase latency 2. Costs go up overall – just shifting costs around 3. Foolhardy to assume you can route to someone else's network better than they can "MEDs are a useful tool for Peering" - patrick 1. Judicious use of MEDs can improve performance 2. MEDs can remove the technical objections to peering 3. It's foolhardy to assume other people can route properly inside their own network. • Audience votes "Which side made the more compelling case" Group Answer: Patrick did - "MEDs are useful for Distributing Peering Load" • Audience added in points that were not made during the debate, or reinforce positions that you believe needed reinforcement. • Audience voted "Are MEDs a useful tool for Peering?" Group Answer: "MEDs are useful for Distributing Peering Load" 5) Peeringdb.com • Peering Contact Information goes out of date very quickly 7) Peering Personals • If you are a peering coordinator, stand up • If you are an IX, sit down • Look around the room • Point with two hands the people that you know the least We had a few folks stand up and introduce themselves, their ASN, their network, what they are looking for in a peer, and why the group should want to peer with them. 6) AS7018 & AS7132 Discussion With the merger of two of the largest peering companies in the U.S. Peering Ecosystem there are questions in the Peering Community about the near and medium term impacts. Ren Provo (AS7132) and Susan Martens (AS7018) stood up and announced the website for peering: http://www.att.com/peering/ and that things were pretty much business as usual now. -- //------------------------------------------------ // William B. Norton <wbn(a)equinix.com> // Co-Founder and Chief Technical Liaison, Equinix // GSM Mobile: 650-315-8635 // Skype, Y!IM: williambnorton

1 0