Transcript NLR Fanout: How in Heck are We Going to Do This?

6nd 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 1st 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 <no topic>.
• 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 1st 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.
Lab-7505
.2
I1 + I2
PARTICIPANT
static to
192.168.200.0/24
10.10.4/30
All Traffic
2547 TEST
Fxp1.0
.1
O3
10.100.1.3/32
.1
.2
fxp0
10.0.3/30
.2
O1
10.100.1.1/32
fxp1.1
fxp1.0
10.10.2/30
I2 Traffic
MAX
AS10
&
OSPF
Aggregate
10.0.0.0/8
fxp0
.1
.1
fxp0
10.0.2/30
.1
fxp0
10.0.1/30
O2
10.100.1.2/32
fxp2.0
.1
.2
fxp1
.1
10.10.0/30
.2
fxp1.1
O6
10.10.3/30
ISP traffic
.2
fxp1
10.10.1/30
AS400
ABILENE
.2
fxp1
AGGREGATE
172.100.0.0/16
O4
O5
AS200
AGGREGATEPARTICIPANT
192.168.100.0/24
192.200.0.0/16
AS300
QWEST
AGGREGATE
15.0.0.0//8
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 semipermanent 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.