6 nd Gigapop Geeks BOF Dan Magorian & Jon-Paul Herron, Cochairs Welcome!! The forum where Gigapop/RON operators can rant, rave, and be politically incorrect about current hot technical topics. And these days, figure out how we’re actually going to get things to work after the politics settles. This room is “CIO-free”. Blast from the past: the 1 st meeting was in Jan 04 in HI, and the topic was “NLR fanout: How the heck are we going to do this?” Now, 2 ½ years later, we’re still talking about more or less the same topic. Kind of sad, isn’t it? The Europeans have built a whole generation of advanced nets while the CIOs have been “discussing” ours.

I hope at this stage of the game that no one is taking a naïve view “We’re just techies. The CIOs control the politics, we can’t influence that. They’ll decide whether we hook up to Newnet and/or NLRnet, and after the dust settles we’ll make whatever they come up with work.” To quote Red Dwarf, “Wrong, wrong, brimming over with wrongability”. Those guys have shown that they can’t manage their way out of a wet paper bag. The Geeks are the ones actually running things, and we better be making the decisions as well. Take charge of your destiny!

Tonight’s Topics Routing, what else? 8-) Seriously, with Newnet /Oldnet /NLRnet/ Current Commodity/ Future Commodity/ Commodity Transit, a heck of a lot of policy routing will soon be happening, if it isn’t already. Gigapops that offer “one size fits all”, and don’t use MPLS VRFs or some other mechanism, are likely to get hosed. So transition into the new complex L3 world is one set of topics. Another is “Lambdas on demand: will they ever touch your production IP network, and if so, how?” In other words, “Hybrid… what the heck will we do about dynamic provisioning?”

Tonight’s speakers Matt Davy, well known to everyone from IU and Abilene, talking on. Dan, stirring up trouble and surprisingly, NOT banging the drum again for why MPLS is good for you even with lots of lambdas at your fingertips. Jon-Paul, exercising crowd control. You. Come on, guys, we’re all heard dozens of presentations and are sick of the politics. Let’s talk about how we’re going to actually do this. What is your plan? What’s worrying you? How do you see it happening, and where do you want it to go? We can talk about both shorter term (eg, newnet transitioning) and longer term issues.

What is the state of RONs today? L3: some still have routers at each pop, some use L1/L2 backhaul over regional/ state fiber to centralized routers. 10G router ints too expensive. L1: most have dwdm systems over fiber, tho a few still don’t. Many now have lambdas stitched up over NLR or otherwise between cities for special projects. Eg, NGIX-E/MANlan are >>finally<< bringing up the AtlanticWave lambda NYC/DC to create the 1 st leg of east coast distributed peering. It’s a safe bet that no one yet really has dynamic lambda services in production, despite all the announcement hype and talks we’ve seen about it

Hybrid… what the heck will we do about dynamic provisioning? For classic “IP heads”, the whole reinventing of circuit-switched approach is suspicious. For those folks, transport should stay in its place and not get uppity. Bring the circuit up, bring up protocols, do the control at L3. The idea of transport moving under the feet of protocols like bgp is scary, and they’re frankly skeptical. This is the way the world works now, and generally it works well except for big flows and corner cases So from that view, transition of the data network is top priority, and “bag on the side” lightpaths to solve special cases are fine but don’t matter much.

Hybrid… what the heck will we do about dynamic provisioning? (part 2) Everyone’s heard Rick and Jerry’s talks, and maybe seen Chris Tracy’s HOPI demos. We’re not going to repeat those here. Subset of people have drunk that cool aid and believe that dynamic provisioning is at least an interesting potential approach for R & E nets. Obviously I2 is pretty strongly behind it, and it seems likely that could be a differentiator between Newnet and NLRnet service offerings. Research is fine, but how should RON operators plan integration of dynamic service offerings? Wait and see? Do we at MAX have a detailed plan? No. We’re at early stages of thinking about integrating separate research and production nets

One vision of a Gigapop Geeks 2008 topic is that We’ll all have gmpls-speaking dwdm systems, that will be pass topology information and broker bandwidth requests dynamically, with solved supporting authentication and measurement infrastructures, fully integrated with our IP nets. Yeah, right. I haven’t drunk that much cool aid. More likely is something in between: that we’ll still be wrestling with many of those issues, but that we’ll hopefully have made some progress. That some experiments will have worked and some failed, but that at least we’ll have stopped bickering and caught back up with the Europeans.

All right, here are a few MPLS VRF thoughts (you knew I couldn’t resist) If you’re considering letting MPLS onto your network to solve policy routing issues, don’t panic at the increased complexity. Max has run ours successfully since 2004 w/o major issues. VRFs are well supported by Juniper and Cisco and even work on 6500/7600s these days. Testing before you deploy is essential. You need to mock it up with at least 5-6 routers. What, your Ron doesn’t have a test lab? Tell your CIOs you really need one. Schedule time in your local Cisco/Juniper customer POC lab.

More MPLS thoughts LDP vs RSVP is a preference issue, both work fine. LDP is easier, automagically sets up full mesh of best-effort LSPs, but is “squishy net”. Numbers change around, can’t nail down hard. RSVP takes more planning initially, but allows traffic engineering (if you care about that) and allows compulsive folks to lay out semi- permanent LSPs with meaningful names instead of autonumbering. Downside is, easier to make mistakes (remember that they’re unidirectional) with complex topologies. Also can do both (RSVP takes priority), but why drive yourself crazy?

Some final MPLS thoughts Your major limitations are RP memory: # of VRFs x # of routes each, PLUS the need for multiple peerings/vlans customer (an int has to be in 1 VRF) Think carefully about whether you’ll need blended VRFs (route bleeding). Depends on whether you’re retrofitting a large network (yes) or starting from scratch w/multiple peerings/customer (eg, MAX) Eg, a large state R&E network that previously offered “one size fits all” has 300 peerings. They’re not going to establish second peerings for everyone to Newnet and NLRnet, so they create blended VRFs and flip participants between.