January 2008 - NANOG - lists.nanog.org

NANOG 42 Draft Agenda Announcement
by Todd Underwood 10 Jan '08

10 Jan '08

* puts Program Committee Chair hat on The NANOG Program Committee is happy to announce that a draft agenda is available for NANOG 42 to be held February 17-20 in San Jose, California. We were extremely pleased with the quality and quantity of submissions this time and will unfortunately have to turn down a number of recent submissions due to lack of space in the agenda. We're happy to announce that our Keynote will be given by Tom Killalea, VP of Technology at Amazon.com, along with Dan Cohn, Principle Network Engineer at Amazon.com. If you are a submitter and have not heard from the Program Committee regarding your submission, please contact me. Dates to be aware of: January 17: Early registration discount ends. If you plan to attend NANOG 42, just register now and get it out of the way already! :-) January 17: Lighting Talk registration opens. January 28: Hotel room block closes. In the past hotel rooms have occassionally run out before then. Again, just look at how great this agenda is and register already. Both tasks can be accomplished by links at http://www.nanog.org/ [The draft agenda follows. Caveats: speakers, topics and times subject to change, errors are my fault, many talks are concurrent, void where prohibited, etc.)] --------------------------------------------------------------------------------------------------- Sunday, February 17 --------------------------------------------------------------------------------------------------- Time Topic Presenter ---------------- ---------------------------------------------- ----------------------------------- 2:00pm - 3:30pm BGP Troubleshooting Techniques, Pt. 1 Philip Smith, Cisco Systems You Can Teach Problem Solving and Should Elizabeth Zwicky L2 Attacks & Mitigation Techniques Yusuf Bahaiji, Cisco Systems 3:30pm - 4:00pm Break & PGP Key Signing 4:00pm - 5:30pm BGP Troubleshooting Techniques, Pt. 2 Philip Smith, Cisco Systems Network Core Infrastructure, Best Practices Yusuf Bahaiji, Cisco Systems Security BoF Danny McPherson, Arbor Networks 5:30pm - 6:30pm NANOG Community Meeting --------------------------------------------------------------------------------------------------- Monday, February 18 --------------------------------------------------------------------------------------------------- Time Topic Presenter ---------------- ---------------------------------------------- ----------------------------------- 9:00 - 10:00 Newcomer's Breakfast Ren Provo, Comcast Continental Breakfast, access to meeting rooms, and network access Sponsors: (pending) 10:00 - 10:30 Opening Remarks Todd Underwood, Renesys John Savageau, CRG West 10:30 - 11:30 Keynote Presentation Tom Killalea and Dan Cohn, Amazon 11:30 - noon Break & PGP Key Signing Noon - 12:30pm Can ISP's and P2P Work Together Laird Popkin, Pando Networks Doug Pasko, Verizon 12:30pm - 1:00pm (pending) 1:00pm - 2:00pm Lunch 2:00pm - 3:30pm Panel: Green Data Centers Moderator: Martin Levy, Tier 1 Research 3:30pm - 4:00pm Break & PGP Key Signing 4:00pm - 5:30pm IX Operators BoF Moderator: Mike Hughes, LINX Small Operator Lessons Learned Pete Templin, Textlink 5:30pm - 7:30pm Bear & Gear Sponsors: (pending) --------------------------------------------------------------------------------------------------- Tuesday, February 19 --------------------------------------------------------------------------------------------------- Time Topic Presenter ---------------- ---------------------------------------------- ----------------------------------- 9:00 - 10:00 Continental Breakfast, access to meeting rooms, and network access 10:00 - 10:30 Lightning Talks ***The window for submissions opens 17-Jan-08*** 10:30 - 11:00 Aftershocks from the Taiwan Earthquakes: Shaking up Internet transit in Asia Martin A. Brownn, Renesys Corporation 11:00 - 11:30 100G: Standards Track Update Greg Hankins, Force 10 11:30 - noon Break & PGP Key Signing Noon - 1pm Panel: 100G Forwarding Achitecture Challenges Ted Seely, Sprint and Igor Gashinsky, Yahoo, Moderators 1:00pm - 2:00pm Lunch 2:00pm - 2:30pm Analysis of PTR Queries for IPv4 Addresses Reserved for Future Allocation Leo Vegoda, IANA (ICANN) 2:30pm - 3:00pm A Simple and Efficient 0(50msec) Resilience Technology for IPTV Dino Farinacci, Cisco Systems Clarence Filsfils, Cisco Systems 3:00pm - 3:30pm Graceful Restart and/or Non-Stop Routing with Stateful Switchover and Non-Stop Forwarding Ken Weissner, Cisco Systems 3:30pm - 4:00pm Break & PGP Key Signing 4:00pm - 5:30pm Peering BoF Bill Norton, Equinix Speaker: Efficient Technique for Enforcing Internet Peering Policies, David J. Smith, Cisco Systems Introduction to IPv6 Philip Smith, Cisco Systems 6:00pm - 8pm CRG Hosted Reception, offsite --------------------------------------------------------------------------------------------------- Wednesday, February 20 --------------------------------------------------------------------------------------------------- Time Topic Presenter ---------------- ---------------------------------------------- ----------------------------------- 8:30 - 9:30 Continental Breakfast, access to meeting rooms, and network access 9:30 - 10:00 Lightning Talks The window for submissions opens 17-Jan-08 10:00 - 10:30 (pending) 10:30 - 11:00 Break & PGP Key Signing 11:00 - 11:30 10G Pluggable Technology Richard Steenbergen, nLayer Communications 11:30 - 12:30 Future Note Surprise Speaker 12:30pm Closing Remarks Todd Underwood, Renesys Corporation -- _____________________________________________________________________ todd underwood +1 603 643 9300 x101 renesys corporation todd(a)renesys.com http://www.renesys.com/blog

1 0

RE: ISPs slowing P2P traffic...
by Joe St Sauver 09 Jan '08

09 Jan '08

Deepak mentioned: #However, my question is simply.. for ISPs promising broadband service. #Isn't it simpler to just announce a bandwidth quota/cap that your "good" #users won't hit and your bad ones will? Quotas may not always control the behavior of concern. As a hypothetical example, assume customers get 10 gigabytes worth of traffic per month. That traffic could be more-or-less uniformly distributed across all thirty days, but it is more likely that there will be some heavy usage days and light usage days, and some busy times and some slow times. Shaping or rate limiting traffic will shave the peak load during high demand days (which is almost always the real issue), while quota-based systems typically will not. Quota systems can also lead to weird usage artifacts. For example, assume that users can track how much of their quota they've used -- as you get to the end of each period, people may be faced with "use it or lose it" situations, leading to end-of-period spikes in usage. Quotas (at least in higher education contexts) can also lead to things like account sharing ("Hey, I'm out of 'credits' for this month -- you never use yours, so can I login using your account?" "Sure..." -- even if acceptable use policies prohibit that sort of thing) And then what do you do with users who reach their quota? Slow them down? Charge them more? Turn them off? All of those options are possible, but each comes with what can be its own hellish pain. And finally, manipulating all types of total traffic could also be bad if customers have a third party VoIP service running, and you block/throttle/other wise mess with untouchable voice service traffic when they need to make a 911 call or whatever. #Operationally, why not just lash a few additional 10GE cross-connects #and let these *paying customers* communicate as they will? I think the bottleneck is usually closer to the edge... Part of the issue is that consumer connections are often priced predicated on a relatively light usage model, and an assumption that much of that traffic may may be amenable to "tricks" (such as passive caching, or content served from local Akamai stacks, etc. -- although this is certainly less of an issue than it once was). Replace that model with one where consumers actually USE the entire connection they've purchased, rather than just some small statistically multiplexed fraction thereof, and make all traffic encrypted/opaque (and thus unavailable for potential "optimized delivery") and the default pricing model can break. You then have a choice to make: -- cover those increased costs (all associated with a relatively small number of users living in the tail of the consumption distribution) by increasing the price of the service for everyone (hard in a highly competitive market), or -- deal with just that comparative handful of users who don't fit the presumptive model (shape their traffic, encourage them to buy from your competitor, decline to renew their contract, whatever). The later is probably easier than the former. #I don't see how Operators could possibly debug connection/throughput #problems when increasingly draconian methods are used to manage traffic #flows with seemingly random behaviors. This seems a lot like the #evil-transparent caching we were concerned about years ago. Middleboxes can indeed make things a mess, but at least in some environments (e.g., higher ed residential networks), they've become pretty routine. Network transparency should be the goal, but operational transparency (e.g., telling people what you're doing to their traffic) may be an acceptable alternative in some circumstances. #What can be done operationally? Tiered service is probably the cleanest option: cheap "normal" service with shaping and other middlebox gunk for price sensitive populations with modest needs, and premium clear pipe service where the price reflects the assumption that 100% of the capacity provisioned will be used. Sort of like what many folks already do by offering "residential" and "commercial" grade service options, I guess... #For legitimate applications: # #Encouraging "encryption" of more protocols is an interesting way to #discourage this kind of shaping. Except encryption isn't enough. Even if I can't see the contents of packets, I can still do traffic analysis on the ASNs or FQDNs or IPs involved, the rate and number of packets transfered, the number of concurrent open sessions open to a given address of interest, etc. Encrypted P2P traffic over port 443 doesn't look the same as encrypted normal web traffic. :-) Unless you have an encrypted pipe that's *always* up and always *full* (padding lulls in real traffic with random filler sonets or whatever), and that connection is only exchanging traffic with one and only one remote destination, traffic analysis will almost always yield interesting insights, even if the body of the traffic is inaccessible. #Using IPv6 based IPs instead of ports would also help by obfuscating #protocol and behavior. Even IP rotation through /64s (cough 1 IP per #half-connection anyone). Some traffic also stands out simply because only "interesting people" exhibit the behavior in question. :-) That could be port hopping, or nailing up a constantly full encrypted connection that only talks to one other host. :-) #My caffeine hasn't hit, so I can't think of anything else. Is this #something the market will address by itself? I think so. At some point there's sufficient capacity everywhere, edge and core, that (a) there's no pressing operational need to shape traffic, and (b) the shaping devices available for the high capacity circuits are prohibitively expensive. That's part of the discussion I offered in "Capacity Planning and System and Network Security," a talk I did for the April '07 Internet2 Member Meeting, see http://www.uoregon.edu/~joe/i2-cap-plan/internet2-capacity-planning.ppt (or .pdf) at slides 44-45 or so. I'd also note that if end user hosts are comparatively clean and under control, traffic from a few "outlier" users is a lot easier to absorb than if you're infested with zombied boxes. In some cases, those bumps in the wire may not be targeting P2P traffic, but rather artifacts associated with botted hosts which are running excessively hot. Regards, Joe St Sauver (joe(a)oregon.uoregon.edu) Disclaimer: all opinions strictly my own.

1 0

Temperature Issues at Equinix Ashburn
by Deepak Jain 09 Jan '08

09 Jan '08

We've just seen equipment @ Equinix Ashburn spike +3C in a 5 minute window. Our input temps are now over 90degrees F. Is anyone else seeing similar issues (while we wait for EQIX to respond).. Thanks in advance, DJ

1 0

Using x.x.x.0 and x.x.x.255 host addresses in supernets.
by Joshman at joshman dot com 09 Jan '08

09 Jan '08

Hello all, As a general rule, is it best practice to assign x.x.x.0 and x.x.x.255 as host addresses on /23 and larger? I realize that technically they are valid addresses, but does anyone assign a node or server which is a member of a /22 with a x.x.x.0 and x.x.x.255? Is it just a manner of preference on whether or not to use them, or are there functional reasons you shouldn't; either with rfc 1918 addresses or public addresses. Thanks in advance, J --------------------------------- Never miss a thing. Make Yahoo your homepage.

9 12

IPv6 Reality Check [Was: Re: IPv6 connectivity mandates?]
by Paul Ferguson 09 Jan '08

09 Jan '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Valdis.Kletnieks(a)vt.edu wrote: >On Mon, 07 Jan 2008 14:58:27 EST, "Justin M. Streiner" said: >> Has anyone seen any indication that, given the US government's push to >> deploy IPv6, they will start (or perhaps they've started already?) >> writing mandates for applicant networks to have IPv6 connectivity into >> the >> requirements for federally funded grants? > >I haven't seen any. But we've been doing IPv6 for so long that it >wouldn't make a notice in our network group - people would just check it off as "BTDT", perhaps after calling our helpdesk and asking "Do we have it" and being told "Yes". > As with most Internet-related issues, the "market" will indeed decide. It amazes me how many times we revisit this issue. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFHhGh+q1pz9mNUZTMRAnM9AKDjm8KzlJSEA7C7mOOcSSY0AEIg1QCfbax7 modWuSZPtckh6auU5jztER4= =iLJ+ -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/ Please note: message attached

1 0

IPv6 connectivity mandates?
by Justin M. Streiner 09 Jan '08

09 Jan '08

Given all of the discussion about IPv6 on this last over the past several weeks, I figured I'd chum the waters a bit more :) This is mainly for people working in colleges and universities, but could apply to ISP/NSPs as well. Has anyone seen any indication that, given the US government's push to deploy IPv6, they will start (or perhaps they've started already?) writing mandates for applicant networks to have IPv6 connectivity into the requirements for federally funded grants? Is anyone seeing anything similar outside of the United States? Thanks jms

4 3

can the memory technology save the routing table size scalability problem?
by yangyang. wang 09 Jan '08

09 Jan '08

As we known, the DFZ RIB size expand rapidly. It may be resolved via router architecture improvement, such as adding memory chips or compressing RIB. or via changing routing and addressing scheme, which one will be the long-term essential approach?

3 2

Re: Using x.x.x.0 and x.x.x.255 host addresses in supernets.
by Scott Weeks 09 Jan '08

09 Jan '08

--- rs(a)seastrom.com wrote: "Wayne E. Bouchard" <web(a)typo.org> writes: > So my oppinion is don't hesistate to use it until you find a real, > reproducible problem. Tell that to your call center manager. :-) ------------------------------------------ I've been using them for several years and no problems. We assign about a /15s worth of DHCP in /23s and use the middle .255 and .0 with zero calls of trouble. The first and last .0 and .255 in the /23 aren't used due to DHCP software silliness. scott

1 0

[admin] Using the NANOG list as a paging mechanism
by Martin Hannigan 09 Jan '08

09 Jan '08

Hi Folks, We'd like to politely note that paging each other on the list without content or context is generally off-topic. These messages are perceived by many as fragments that are not useful to the wider community. If you could provide some level of detail as to why you are using the list to reach someone, it would be much appreciated. There are many benefits to this approach including more eyes on the issue (and the message) as well as a faster MTTR. If the issue is not involving the public Internet, then it's probably safe to conclude that a private approach may be better. Best Regards, Martin Hannigan NANOG Mailing List Committee

8 8

Re: Assigning IPv6 /48's to CPE's?
by Rick Astley 08 Jan '08

08 Jan '08

>* /32 for ISPs unless they can justify more >* /48 for subscribers unless they can justify more >* /64 when you know for certain that one and only one subnet will ever be required >* /128 when you know for certain you're dealing with a single device >* Sparse allocation so whichever size you choose you can usually increase it by simply changing the prefix length. So if /64 is "subnet" rather than "node" then the practice of placing one and only one node per subnet is pretty wasteful. And giving residential users a /48 will leave them with 80 bits for addressing. Even if the household was using 1,000,000,000,000,000 IP addresses in their home, this would mean that they are still not using 99.9999999% of the IP addresses they have been allocated. I know the reason for this is becasue they are allocated IP's based on number of possible subnets, rather than total number of available IP's, so it would be more fair to say they are allocated 65,536 subnets. So Acme DSL has been given a /32 from ARIN. Bob their administrator promptly decides it is a good idea to just give each customer a /48 becasue who knows /what/ their needs may be. This gives Acme Bob enough IP addresses for 2^(48-32) or 65,536 customers assuming bob uses none of these IP addresses for his own equipment and has a single homed network. If Bob has a multihomed network, he can't just give one /48 to a customer in NY and the next one to a customer in CA unless he wants to fill up Internet routing tables with /48's, so he will have to assign large aggregate blocks to each region. Accommodating for this, Bob is unlikely to plan for more than 30% utilization in any one region, with most being less and some aggregate blocks withheld entirely for growth. So lets say Acme DSL's IPv6 deployment places them in the ballpark of 10% utilization (not bad considering end users are wasting 99.99999999999999999999%), this gives them enough blocks for only 6,500 customers. Take someone like Comcast with ~12 million subscribers. It would take an IPv6 /24 to get 16.7 million /48's (2^24). With a net efficiency of 10% they are going to need to be allocated 120 million /48's. It would take a /21 to give them 2^(48-21) = ~134 million /48's. So in short, a /48 to subscribers seems like complete overkill, and a /32 to ISP's seems completely inadequate (80 vs 16 bits). I thought one of the goals of IPv6 was to assign ISP's huge blocks with low utilization so they don't have push a bunch of individual prefixes out to the worlds routing tables? It seems to me while being extra super sure we meet goal 1 of making sure NAT is gone for ever (and ever) we fail goal 2 of not allocating a bunch of prefixes to ISP's that are too small.

23 40