Here's my notes from this morning's sessions. 
Off to lunch now!
Matt
2009.10.20 NANOG day 2 notes, first half
Dave Meyer kicks things off at 0934 hours
Eastern time.
Survey! Fill it out!
http://tinyurl.com/nanog47
Cathy Aaronson will start off with a rememberance
of Abha Ahuja. She mentored, chaired working
groups, she helped found the net-grrls group;
she was always in motion, always writing software
to help other people. She always had a smile, always
had lots to share with people.
If you buy a tee shirt, Cathy will match the donation.
John Curran is up next, chairman of ARIN
Thanks to NANOG SC and Merit for the joint meeting;
Add your operator perspective!
Vote today in the NRO number council election!
You can vote with your nanog registration email.
https://www.arin.net/app/election
Join us tonight for open policy hour (this room)
and happy hour (rotunda)
Participate in tomorrow's IPv6 panel discussion
and the rest of the ARIN meeting.
You can also talk to the people at the election
help desk.
During the open policy hour, they'll discuss the
policies currently on the table.
And please join in the IPv6 panel tomorrow!
If you can, stay for the ARIN meeting, running
through Friday.
This includes policy for allocation of ASN blocks
to RIRs
Allocation of IPv4 blocks to RIRs
Open access to IPv6 (make barriers even lower)
IPv6 multiple discrete networks (if you have non
connected network nodes)
Equitable IPv4 run-out (what happens when the free
pool gets smaller and smaller!)
Tomorrow's Joint NANOG panel
IPv6--emerging success stories
Whois RESTful web service
Lame DNS testing
Use of ARIN templates
consultation process ongoing now; do we want to
maintain email-based access for all template types?
Greg Hankins is up next for 40GbE and 100GbE
standards update--IEEE P802.3ba
Lots of activity to finalize the new standards specs
many changes in 2006-2008 as objectives first developed
After draft 1.0, less news to report as task force
started comment resolution and began work towards the
final standard
Finished draft 2.2 in august, crossing Is, dotting Ts
Working towards sponsor ballot and draft 3.0
On schedule for delivery in June 2010
Copper interface moved from 10meter to 7meter.
100m on multimode,
added 125m on OM4 fiber, slightly better grade.
CFP is the module people are working towards as
a standard.
Timeline slide--shows the draft milestones that
IEEE must meet. It's actually hard to get hardware
out the door based around standards definitions.
If you do silicon development and you jump in too
fast, the standard can change under you; but if you
wait too long, you won't be ready when the standard
is fully ratified.
July 2009, Draft 2 (2.2), no more technical changes,
so MSAs have gotten together and started rolling
out pre-standard cards into market.
Draft 3.0 is big next goal, it goes to ballot for
approval for final standards track.
After Draft 3.0, you'll see people start ramping
up for volume production.
Draft 2.x will be technically complete for WG ballot
tech spec finalized
first gen pre-standard components have hit market
technology demonstrations and forums
New media modules:
QSFP modules
created for high density short reach interfaces
(came from Infiniband)
Used for 40GBASE-CR4 and 40GBASE-SR4
CXP modules
proposed for infiniband and 100GE
12 channels
100GbE uses 10 of 12 channels
used for 100GBASE-10
CFP Modules
long reach apps
big package
used for SR4, LR4, SR10, LR4, ER4
about twice the size of a Xenpak
100G and 40G options for it.
MPO/MTP cable
multi-fiber push-on
high-density fiber option
40GBASE-SR4
12 fiber MPO uses 8 fibers
100GBASE-SR10
24 fiber MPO cable, uses 20 fibers
this will make cross connects a challenge
Switches and Routers
several vendors working on pre-standard cards,
you saw some at beer and gear last night.
Alcatel, Juniper
First gen tech will be somewhat expensive and
low density
geared for those who can afford it initially and
really need it.
Nx10G LAG may be more cost effective
higher speed interfaces will make 10GbE denser and
  cheaper
Density improves as vendors develop higher capacity
systems to use these cards
  density requires > 400Gbps/slot for 4x100GbE ports
Cost will decrease as new technology becomes feasible.
Future meetings
September 2009, Draft 2.2 comment resolution
Nov 2009 plenary
Nov 15-20, Atlanta
Draft 3.0 and sponsor ballot
http://grouper.ieee.org/groups/802/3/ba/index.html
You have to go to meeting to get password for the
draft, unfortunately.
Look at your roadmap for next few years
get timelines from your vendors
optical gear, switches, routers
server vendors
transport and IP transit providers, IXs
Others?
figure out what is missing and ask for it
will it work with your optical systems
what about your cabling infrastructure
40km 40GbE
Ethernet OAM
Jumbo frames?
There's no 40km offering now; if you need it,
start asking for it!
Demand for other interfaces
standard defines a flexible architecture, enables
many implementations as technology changes
Expect more MSAs as tech develops and becomes cost
effective
serial signaliing spec
duplex MMF spec
25Gbps signalling for 100GbE backplane and copper
  apps
Incorporation of Energy Efficient Ethernet (P802.3az)
to reduce energy consumption during idle times.
Traffic will continue to increase
Need for TbE is already being discussed by network
operations
Ethernet will continue to evolve as network requirements
change.
Question, interesting references.
Dani Roisman, PeakWeb
RSTP to MST spanning tree migration in a live datacenter
Had to migrate from a Per-vlan RSTP to MST on a
highly utilized network
So, minimal impact to a live production network
define best practices for MST deployment that will
yield maximal stability and future flexibility
Had minimal reference material to base this on
Focus on this is about real-world migration details
read white papers and vendor docs for specs on each
type.
The environment:
managed hosting facility
needed flexibility of any vlan to any server, any rack
each customer has own subnet, own vlan
Dual-uplinks from top-of-rack switches to core.
High number of STP logical port instances
using rapid pvst on core
Multiple VLAN*interface count = logical port instances
Too many spanning tree instances for layer 3 core switch
concerns around CPU utilization, memory, other resource
exhaustion at the core.
Vendor support: per-vlan STP
Cisco: per-vlan is the default config, cannot switch
to single-instance STP
foundry/brocade offers per vlan mode to interoperate
with cisco
Juniper MX and EX offers vstp to interoperate
Force10 FTOS
Are we too spoiled with per-vlan spanning tree?
don't need per-vlan spanning tree, don't want to
utilize alternate path during steady-state since
we want to guarantee 100% capacity during
failure scenario
options:
collapse from per-vlan to single-instance STP
Migrate to standards-based 802.1s MSTP
(multiple spanning tree--but really going to fewer
spanning trees!)
MST introduces new configuration complexity
all switches within region must have same
vlan-to-mst mapping
means any vlan or mst change must be done
universally to all devices in site.
issues with change control; all rack switches
must be touched when making single change.
Do they do one MST that covers all vlans?
Do they pre-create instances?
do all vendors support large instance numbers?
No, some only support instances 1-16
Had to do migration with zero downtime if possible
Used a lab environment with some L3 and L2 gear
Found a way to get it down to one STP cycle of 45secs
Know your roots! Set cores to "highest" STP priority
(lowest value)
Set rack switches to lower-than-default to ensure
they never become root.
Start from roots, then work your way down.
MSTP runs RSTP for backwards compatability
choose VLAN groups carefully.
Instance numbering
some only support small number, 1-16
starting point
all devices running 802.1w
core 1 root at 8192
core 2 root at 16384
You can pre-config all the devices with spanning
tree mapping, but they don't go live until final
command is entered
Don't use vlan 1!
set mst priority for your cores and rack switches.
don't forget MST 0!
vlan 1 hangs out in MST 0!
First network hit; when you change core 1 to
spanning mode mst
step 2, core2 moves to mst mode; brief blocking
moment.
step 3; rack switches, one at a time, go into
brief blocking cycle.
Ongoing maintenance
all new devices must be pre-configured with identical
MST params
any vlan to instance mapping changes, do to core 1
first
no protocol for MST config propagation
vtp follow-on?
MST adds config complexity
MST allows for great multi-vendor interoperability in
a layer 2 datacenter
only deployed a few times--more feedback would be
good.
Q:
Leo Bicknell, ISC; he's done several; he points
half rack switches at one core, other half at
other core; that way in core failure, only half
of traffic sloshes; also, on that way with traffic
on both sides, failed links showed up much more
quickly.
Any device in any rack has to support any vlan
is a scaling problem. Most sites end up going
to Layer3 on rack switches, which scales much
better.