September 2007 - Test - lists.nanog.org

shameful-cabling gallery of infamy - does anybody know where it went?
by Valdis.Kletnieks＠vt.edu 06 Sep '07

06 Sep '07

http://gallery.colofinder.net/shameful-cabling had a great collection of "What not to do" photos, but it has apparently evaporated in the mists of time. Anybody know if it's at a new location, or is the Wayback Machine my only hope? (ISTR it also had an adjacent "cabling done right" gallery - does that survive?)

7 6

Congestion control train-wreck workshop at Stanford: Call for Demos
by nanditad＠stanford.edu 06 Sep '07

06 Sep '07

Congestion control train-wreck workshop at Stanford: Call for Demos We would like to invite you to a two-day congestion control workshop, titled "Train-wrecks and congestion control: What happens if we do nothing?", which we are hosting at Stanford on 31 March - 1 April, 2008. Spurred on by a widespread belief that TCP is showing its age and needs replacing - and a deeper understanding of the dynamics of congestion control - the research community has brought forward many new congestion control algorithms. There has been lots of debate about the relative merits and demerits of the new schemes; and a standardization effort is under way in the IETF. But before the next congestion control mechanism is deployed, it will need to be deployed widely in operating systems and - in some cases - in switches and routers too. This will be a long road, requiring the buy-in of many people: Researchers, product developers and business leaders too. Our own experience of proposing new congestion control algorithms has been met with the challenge: "Show me the compelling need for a new congestion control mechanisms?", and "What will really happen to the Internet (and my business) if we keep TCP just the way it is?" As a community, we need examples that are simple to understand, and demonstrate a compelling need for change. We call them the "Train wreck scenarios". Examples might show that distribution of video over wireless in the home will come to a halt without new algorithms. Or that P2P traffic will bring the whole network crashing down. Or that huge, high-performance data-centers need new algorithms. Whatever your favorite example, we believe that if we are collectively armed with a handful of mutually agreed examples, it will be much easier to make a business case for change. Or put another way, if we can't articulate compelling examples to industry leaders, then is the cost and risk of change worth it? The goal of the workshop is to identify a handful of really compelling demonstrations of the impending train-wreck. The outcome will be a set of canonical examples that we will use to persuade industry of the need for change. We are deliberately inviting you many months ahead of time - to give you time to create your compelling train-wreck demonstration. You can choose the way you present your demonstration: You could bring equipment and show a live-demo; you could show simulations or animations; or you could produce a video showing a real or synthetic demo. Whatever method you choose, the goal is to create a case that will persuade a mildly-technical but influential business leader of the need for change. We will invite a panel of judges to give prizes for the most compelling examples in two categories: (1) The Overall Most Compelling Example, which will be judged on a combination of the technical merits and the presentation of the scenario, and (2) The Most Technically Compelling Example, which will be judged on its technical merit alone, without consideration of the way it is presented. The whole purpose of the workshop it to focus on the {\em problem}, not the solutions. We are most definitely {\em not} interested in your favorite scheme, or ours. So we need some ground-rules. \begin{center} {\em No-one is allowed to mention a specific mechanism, algorithm or proposal at any time during the workshop: Not in their talk, not in a panel, and not in questions to the speakers. The only mechanisms that will be allowed mention are: TCP (in its standard and deployed flavors), and idealized alternatives for purposes of demonstration. For example, comparing TCP with an oracle that provides instantaneous optimal rates to each flow.} \end{center} Attendance to the workshop will be by invitation only - to keep the discussion focused and lively. We will video the entire workshop and all the demonstrations, and make it publicly available on the Internet. We will make any proceedings and talks available too. The goal is to open up the demonstrations for public scrutiny and feedback after the event. The event is hosted by the Stanford Clean Slate Program - http://cleanslate.stanford.edu - and local arrangements will be made by Nick McKeown and Nandita Dukkipati. The workshop has received offers of support and funding from Cisco Systems and Microsoft. We hope to make a limited number of travel grants available. We have a small Program Committee (listed below) to select the final demonstrations. We are soliciting a 1-page description of your demo. Please note the following dates. Important Dates: =============== Workshop: 31 March - 1 April, 2008 1-page demo description submission deadline: 1 Dec, 2007 Notification of acceptance: 15 Dec, 2007 Final demo submissions: 17 March, 2008 Last date for demo withdrawals: 25 March, 2008 Please email your initial 1-page submissions to: Nandita Dukkipati <nanditad(a)stanford.edu> and Nick McKeown <nickm(a)stanford.edu> Best wishes, and we hope to see you in Stanford! Nandita Dukkipati Nick McKeown Program Committee: ================== 1. Albert Greenberg, Microsoft Research 2. Peter Key, Microsoft Research 3. Flavio Bonomi, Cisco 4. Bruce Davie, Cisco 5. Steven Low, Caltech 6. Frank Kelly, Cambridge 7. Lars Eggert, Nokia Research/IETF 8. Nick McKeown, Stanford 9. Guru Parulkar, Stanford 10. Nandita Dukkipati, Stanford/Cisco/Princeton

14 22

TeliaSonera routing issue / microsoft.com
by Pekka Savola 06 Sep '07

06 Sep '07

Hi - TeliaSonera has reported routing problem due to prefix filtering leaks / max-prefix triggering, starting around 0616 UTC. I guess some others are seeing this as well. I wonder what was the more exact reason, and why the problem still persists after about 6 hours. In particular, our customers have noticed this with various sites related to Microsoft, including e.g., VoIP systems failing because contacting some active-x site failed. Is there a looking glass, traceroute server, or sensible contact info for someone at AS 8075 to check what the routing looks like from that perspective? (Traceroute works from our upstream, but not from here, which suggests a potential return path issue for e.g., 193.166.0.0/15, pingable address 193.166.255.241). ;; ANSWER SECTION: www.microsoft.com. 1088 IN CNAME toggle.www.ms.akadns.net. toggle.www.ms.akadns.net. 57 IN CNAME g.www.ms.akadns.net. g.www.ms.akadns.net. 57 IN CNAME lb1.www.ms.akadns.net. lb1.www.ms.akadns.net. 57 IN A 207.46.192.254 lb1.www.ms.akadns.net. 57 IN A 207.46.193.254 lb1.www.ms.akadns.net. 57 IN A 207.46.19.190 lb1.www.ms.akadns.net. 57 IN A 207.46.19.254 1 s-b4-link.telia.net (213.248.97.93) 0.620 ms 0.498 ms 0.409 ms 2 s-bb2-link.telia.net (213.248.66.13) 0.762 ms 0.597 ms 0.721 ms 3 kbn-bb2-pos0-0-0.telia.net (213.248.65.29) 10.231 ms 10.276 ms 10.215 ms 4 nyk-bb2-link.telia.net (213.248.82.101) 94.660 ms 94.670 ms 94.640 ms 5 sjo-bb1-link.telia.net (80.91.254.177) 161.549 ms 161.542 ms 161.530 ms .. stops here. If it works (from upstream) it continues as follows: 6 microsoft-110312-sjo-bb (213.248.86.70) 161.421 ms 161.818 ms 157.519 ms 7 ge-6-3-0-44.sjc-64cb-1a.ntwk.msn.net (207.46.44.98) 161.814 ms 155.456 ms 157.559 ms 8 ge-1-0-0-0.bay-64c-1a.ntwk.msn.net (207.46.37.158) 156.229 ms 158.292 ms 156.223 ms -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

3 2

PKI operators anyone?
by Joe Maimon 06 Sep '07

06 Sep '07

MS-PRESS recommended design guidelines for multi-tier PKI systems for validity periods are along the lines of 8 years for the root 4 years for the "policy" 2 years for the "issuing" 1 year for the issued certificate This is ostensibly due to fears of brute force cracking of the private keys over the root key's validity period. Accompanied with this recommendation is one for key lengths of 4096 for the root 2048 for the policy 1024 for the issuing and for the issued. I have found the downside to this: Constant renewals every single year of either minor or major impact. While MS-AD pki client implementations seem to handle most of the (except for the root) resigning just fine, external implementation struggle with some details, such as "chaining up to the root" trusting (thereby only requiring them to trust the root cert) and such as trusting two different certs (for an issuing CA that gets resigned) but that have the same common name, hence loads of fun every 11 months or so. I am about to recommend a re implementation along these lines 80 years for the root, 4096bit key 35 years for the policy, 4096bit key 15 years for the issuing, ?bit key <=5 years for the issued certificates. Good idea? Bad Idea? Comments? Are all pki client implementation in the wild 4096bit compatible? Thanks in advance, Joe

10 17

RE: PKI operators anyone?
by Paul Ferguson 05 Sep '07

05 Sep '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The only way a successful PKI will be deployed is if the U.S. Government takes a "hands-off" approach. Good luck with all that. $.02, - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj8DBQFG33D9q1pz9mNUZTMRAg92AKC8oqVYWytmwC6Nzl44MKVucKKlvgCfX78t M5Wh+nBltJCqNYa6fiY+thE= =FGmF -----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/

1 0

Draft agenda for NANOG 41
by Steve Feldman 04 Sep '07

04 Sep '07

The NANOG Program Committee is please to announce the draft angenda for the NANOG 41 conference, to be held October 14-16 in Albuquerque, NM: SUNDAY, October 14 - Joint NANOG/ARIN IPv6 Workshop: 8:30am - 4:30pm - Tutorials 1:30pm - 3:00pm BGP Multihoming Techniques (part 1) - Philip Smith, Cisco Systems Layer 3 VPN for v4 & v6 in IP Core - Madhusudan Nanjanagud, Cisco Systems 3:30pm - 5:00pm BGP Multihoming Techniques (part 2) - Philip Smith, Cisco Systems - Newcomers meeting and reception: 3:30pm - 5:00pm - Community meeting - 5:30pm MONDAY, October 15 - General session: 9:00 - 12:30 9:00- 9:30 Opening Remarks 9:30-10:00 Perfect Storms, Internet Economics, and the Future of the Internet - David Meyer, Cisco/Univ. of Oregon 10:00-10:30 Resilient L2 VPNs - Ian Cowburn, Alcatel-Lucent 10:30-11:00 BREAK 11:00-11:30 From NetFlow to IPFIX: the evolution of IP flow information export - Brian Trammell, CERT/NetSA; Elisa Boschi, Hitachi Europe 11:30-12:30 Optical Panel - Moderator: Ted Seely, Sprint - General session: 2:00pm - 3:30pm 2:00- 2:30 LISP: A Level of Indirection for Routing Dino Farinacci, Cisco 2:30- 3:30 LISP-CONS: A Content distribution Overlay Network Service for LISP - David Meyer, Cisco/Univ. of Oregon 3:30- 4:00 Protection and Fault Recovery at Internet Peering Points using 802.1ag CFM - Rahul Vir, Foundry Networks - BOFs: 4:00pm - 5:30pm Peering BOF XVI - Bill Norton, Equinix - Beer 'n Gear - 5:30 - 7:30 TUESDAY, October 16 - General session - 9:00 - 12:00 9:00-10:00 KEYNOTE: Stephen Ryan, General Counsel, American Registry of Internet Numbers (ARIN) and Partner, McDermott, Will and Emery in Washington D.C. 10:00-10:30 BREAK 10:30-11:00 Have We Reached 1000 Prefixes Yet?: A snapshot of the global IPv6 routing table - Gert D�ring, SpaceNet AG, presented by CJ Aronson 11:00-12:00 EOTWAWKI: The end of the world, as we know it - Cathy Aronson, Daydream Imaging & Leo Bicknell, ISC - General session - 1:30 - 5:00 1:30- 2:00 IPv6 Transition & Operational Reality - Randy Bush, IIJ 2:00- 3:00 Lightning Talks! 3:00- 3:30 BREAK 3:30- 4:00 Integrating Networks - Nina Bargisen and Michael Lyngb�l, TDC 4:00- 4:15 Research Forum: BGP Protection Without Global Cooperation - Josh Karlin, University of New Mexico and Stephanie Forrest, University of New Mexico and Jennifer Rexford, Princeton University 4;15- 4:45 TBA 4:45- 5:00 Closing Remarks and Election Results This is a draft agenda, and will be subject to change until the meeting ends. For current information, see http://www.nanog.org. On Sunday, October 14, there will also be a special one-day workshop on IPv6 implementation, jointly sponsored by NANOG and ARIN. The week continues with the ARIN XX meeting on October 17-19. Finally, a few announcements from Merit: Meeting registration (https://www.nanog.org/registration/) is open and the lower registration rate is in effect through September 24. The group room rate at the hotel (http://www.nanog.org/mtg-0710/hotel.html) expires September 24. Note: make your reservation early as NANOG is meeting on the tail end of the International Balloon Fiesta. Hotel rooms will be in high demand, especially on Saturday night, Oct. 13. For additional meeting information, please see http://www.nanog.org/. See you in Albuquerque! Steve Feldman PC Chair

1 0

Re: Congestion control train-wreck workshop at Stanford: Call forDemos
by Christian Kuhtz 04 Sep '07

04 Sep '07

Lmao. Thanks, Sean, I just snorted my cup of freshly brewed coffee. Ouch. :-) ------Original Message------ From: Sean Donelan Sender: owner-nanog(a)merit.edu To: Stephen Stuart Cc: nanog Sent: Sep 4, 2007 10:30 AM Subject: Re: Congestion control train-wreck workshop at Stanford: Call forDemos On Tue, 4 Sep 2007, Stephen Stuart wrote: >>> Operators are probably more interested in the "fairness" part of >>> "congestion" than the "efficiency" part of "congestion." >> >> TCP's idea of fairness is a bit weird. Shouldn't it be per-user, not >> per-flow? > > How would you define "user" in that context? Operators always define the "user" as the person paying the bill. One bill, one user. Its fun to watch network engineers' heads explode. -- Sent from my BlackBerry.

1 0