Presentation on theme: "8th Gigapop Geeks BOF tonight hosted by Dan Magorian Welcome!! The forum where Gigapop/RON operators can rant, rave, and be politically incorrect about."— Presentation transcript:
8th Gigapop Geeks BOF tonight hosted by Dan Magorian Welcome!! The forum where Gigapop/RON operators can rant, rave, and be politically incorrect about current hot technical topics. This room is “CIO-free”. But many techies are managers Last time we tried an NTAC Commodity WG face-to-face –I2 represented by Matt Davy and Steve Wallace of IU. –Great attendance, very successful, very useful discussion. –I2 and IU modified their approach based on that discussion –I2’s Commercial Peering Service now up, NTAC Peering WG done. Tonight 2 discussion topics, one technical, once political. Technical: VRFs, VRFs, and more VRFs: MAX’s experience with MPLS policy routing continues. Political: Let’s talk about DCS and what’s happening
1 st admin issue: future meetings Ana Preston has said that I2 may not be able to keep paying for free food and drink at this BOF –( it’s now her budget, used to be Rick Summerhill’s). –Eg, no wireless or remote callin tonight to save I2 some $. They’ve put out the idea of consolidating it with the Tuesday evening Connectors BOF. I said that I think that while there is some overlap, they serve quite different functions; –The Connectors BOF is from the perspective of I2, mainly for connectors only to feed back on I2 policy and issues –The Geeks BOF can have technical topics for anyone such as routing discussions etc might be unrelated to I2 policy and issues. What do you think? Should this forum continue independently? Warning: you may have to pay for your own beer in future!
Technical Topic: VRFs, vrfs, more vrfs MAX recently connected to NLR’s PacketNet as well as I2 (don’t ask about the politics of this). Despite political pressure to drop that peering in same table and pref it up to push traffic that way, we decided to expand our use of MPLS 2547 VRFs (route table) for policy routing. Why not do “regular approach” that’s common practice? –MAX participants care a LOT about how their traffic flows. –VRFs are ideal sandboxes to test routing w/o breaking everyone’s. We told folks that they now had routing (not fiber path) redundancy available at no extra cost, only if they wanted. If they did want, we’d swing their peering into the new VRF. Did initial lab testing, a handful have taken us up on it so far, many seem to be staying I2 only. Still early days yet.
Previously we’ve done separate peerings for each service Our usual approach is to have “a la carte” routing: create additional peering for new services, mix in customer routers. Have done this for add-on ISP services. We’re proud of not having “one size fits all” service offering. Works well, people are happy with it, means MAX is “clean pipe” giving them all routes, maximum flexibility for customers to pref routes up and down selectively. Also means routing decisions made by their bgp, not ours. Problem is effort to establish additional peerings. Means can’t just swing everyone over: one by one, takes time. If you want to get big cost benefits to gigapop from eg new settlement-free peering services, this approach not for you.
Problem is, it isn’t just one new VRF “ VRFs are darn handy, but they tend to breed like fire ants”. Carl Harris, VT If had luxury of creating additional peerings for NLR, could have continued current straightforward approach. But this didn’t fit with management desire for quick results. To initial I2 VRF, needed to add new VRFs: Packetnet VRF plus “blended” NLR and I2 VRFs. Problem isn’t number of VRFs, because routes in each is small, as long as can keep down number of combinations. Main issue is complexity caused by the “blended” VRFs. Anyone here have experience with route leaking between VRFs? If so, know isn’t as easy as might think.
“Blended” VRFs: an interesting learning experience for MAX. Caveat: Dave Diller is MAX’s chief router jock these days, did most of the work. He’ll talk about it in detail with code snippets at next Jt Techs. We’re also still experimenting, so not fully cooked yet. Tried a bunch of approaches that mostly worked, but had nasty corner cases and some reachability issues. Finally had to harmonize entire pref scheme, and blend both directions: NLR routes into I2-dominant VRF prefed down, & I2 routes into NLR-dominant VRF prefed down. Works pretty well v4 and v6 unicast, still v4 multicast issues What we’ve done is lot of work to give MAX participants choice! Also creates test sandbox only affects few people. More details from Dave next time.
Political discussion topic: What about I2’s Dynamic Circuit Service (DCS)? I invited Rick Summerhill to be here, but was last minute. Maybe someone else from I2 or IU could stand in… As people probably know, DCS is production name for what was developed on HOPI by I2/MAX/IU/MCNC etc, connect to it via Ciena CoreDirector 10G ports. John Graham of IU has played big role is rolling CoreDirector part of Newnet out, very commendable effort. How many people here are connecting to DCS? Plan to? What are your decision factors? My premise: DCS is too expensive for an infant service offering. If fails, could validate what some NLR folks claim: that no one wants anyway. But may be just too expensive for unknown demand. Since charging for circuits too, best would be if ports free. That may not be possible given I2’s investment, but at least free trial period for people to test water, build demand.
Thanks! Any volunteers for talks next time? Discussion topics you’d like to hear? firstname.lastname@example.org