2009.10.20 NANOG47 day 2, second half

Matthew Petach mpetach at netflight.com
Tue Oct 20 23:09:41 UTC 2009


Here's my notes from the second half of the second day at
NANOG, including the peering BoF and the ARIN open
policy hour.

Now for some dinner.  ^_^;

More on the morrow.

Matt



2009.10.20 NANOG day 2 notes, second half

FILL OUT YOUR SURVEY!!
http://tinyurl.com/nanog47

VOTE!!
http://bit.ly/nanogelect

Kevin Epperson welcomes everyone back from
lunch at 1432 hours Eastern time.

Don't forget the survey and the voting!

BJ Neal from FCC will talk about national
broadband plan.

Relax, he's not a lawyer, he's not here
to regulate, he's here to get information
from us.

Looking to get input from some of the
membership here at how they should look
at traffic engineering on backhaul and
shared portions of the network.

In early 2009, President and Congress
tasked FCC to put plan together for
broadband access for all americans,
focusing on rural and underserved
areas.
Feb 17, 2010 the plan is due before Congress.

3 basic components to BB team:
deployment team: technology purposes, funding
 sources, policy levers
national purpose: healthcare, hospitals, schools,
adoption: what needs to be done to encourage adoption
 of BB technology for the underserved and unserved

broadband plan is data driven.
FCC looking for as much real world data as possible
as inputs to the plan as possible.

Need to make sure the plan addresses all three
elements as much as possible, to be as complete
as possible.

On the adoption side, it may be that some people
may have inside wire issues, may need education,
may not be able to afford a computer to connect,
etc.

US has a complex mix of broadband assets
DSL, cable, wireless, FTTp, power line
networking on last mile
Second mile access is copper Xport, fiber
Xport, wireless point-to-point, hybrid copper/fiber
middle mile access is dedicated internet access,
ATM, frame relay, managed IP/MPLS/VPLS,
dedicated private line, DS3, OCn,

Traffic engineering on "shared" portions:
how should BB team tihnk about traffic
engineering, or sizing of the shared or "backhaul"
portions of the network.

Significant impact to the cost of a National BB
network architecture.  Obviously it is very
important to size network properly.

Possibly need an equivalent "erlang" model for
public IP traffic mix; what is the formula for
this?

NANOG member's views on the traffic engineering
and network dimensioning.


Q: Randy Bush, IIJ; fun visiting third world
country; in Tokyo, you just have fiber, and
the last 100meters is 100baseT, and he can
get 80mbits from Tokyo to westin Seattle.
He has a third world connection in Seattle
from a house there, he can get almost 600
from Seattle to Westin, costs 3x as much.
How to do traffic engineering?  Provision it,
and you don't have to do traffic engineering.
A: overprovisioning comes with significant
cost, especially if that means deploying
new fiber.
Q: We said same thing about rural rollouts
of telco; now, farms get upset at busy signals.

Q: Igor from Yahoo notes that traffic engineering
is wrong term; he really means how to plan how
much to provision, not which pathways to send
traffic along.
A: He's looking for oversubscription ratio for
a given set of users with a given set of
applications along the backhaul to a public
interconnection point.
Q: In that case, pick a starting point, and
then build to what the customers use, and
bill them accordingly.
A: FCC doesn't have any traffic numbers to look
at, so they need a starting point.

Q: RAS notes the backhaul from lower tier city
to where you really want to go is really cheap
and easy; most of the cost is last mile.  So
build backhaul with as much capacity as you
need; the government is going to get bad deals
no matter what anyhow.
The vast majority of the cost really is the last
mile.

Q: Jay Moran, AOL, they're looking at many
broadband proposals coming from various people.
Just need to submit the questions to people who
are sending out the VTOP applications.


BGPbotz
IM-based route view bot
Manish Karir

Route Views
Generally web or telnet based
provides a looking glass for BGP from different
vantage points (routers)

Disadvantages
Have to remember telnet/web addresses
route-server.ip.att.net
route-views.ab.bb.telus.com

"more" is a pain.

BGPbotz is up on iM, you can type in similar
commands to it.

It'll give links back if the output is too long;
output survives for an hour, then disappears.

Commands:
show ip bgp
show bgp view (router) ipv6
ping
traceroute
aslookup
whois
grep

Architecture
Python
chat protocols: AIM, Jabber(XMPP)
single thread per user

Results
400+ screen names from both protocols

Results: "show ip bgp" was most popular
command!

Talk to BGPbotz
AIM: bgpbotz
Jabber: bgpbotz at jabber.research.merit.edu

He shows a realtime demo of it

Still looking for more views

source available:
http://bigbotz.merit.edu

Q: Patrick, Akamai, would you do in-addr resolution
on traceroutes?
A: it really makes it slow; they wanted it to be
pretty quick.  Could take a while with long
traceroutes.

Q: Matt, Yahoo, could he add other messenger
platforms like Yahoo or MSN?
A: yes, if the module can provide a python
interface, it can be plugged in.


Geoff Sisson, Duane Wessels
DNS OARC

Root Zone historical trends
NS records, A records, IPv6 AAAA records, TLDs.

In the past year, breaking away from the trend of
one AAAA per TLD.

Interesting times for the DNS root.
IPv6 Glue
DNSSec
New TLDs
IDNs

Also...
Continued Anycast deployment
continued increase in query rates.

This study of root zone changes

ICANN hired OARC to simulate changes to
the root zone and explore how they affect:

The size of the root zone
Server response latency
Server start and reload times

Hardware:
DNS OARC testbed
16 HP prliant DL140 G3 servers
 4 3Ghz cores

Software
testing BIND 9.6.0P1, and NSD 3.2.1
Centos 5.3, FreeBSD 7.1
dnsperf, etc.

Zone file configs
5 types of zone content
unsigned, mostly v4 glue
unsigned, v4 and v6 glue
signed, v6 glue, 10% DS records
signed, v6 glue, 50% DS records
signed, v6 glue, 100% DS records

five zone sizes
1K, 10K, 100K, 1M, 10M

Memory usage
How do root zone changes affect zone size and
memory usage?
Process memory usage measured with pmap.
 includes code memory and shared lib memory

BIND increases at 10K to linear curve.
smaller sizes have more overhead compared to entries.

NSD, 32G RAM couldn't load 10M signed TLD zones.

memory usage proportional to zone size
signed zone uses twice as much memory.

NSD needs more than 32G to hold 10M signed zone

response latency
how does latency of an L-root analog vary as
function of zone size?

BIND, unsigned zone, different sizes generally
about a quarter ms.  Performance does not change
as zone size increases.

NSD, similar graph, very consistent; NSD is slightly
lower latency, .1ms

BIND with signed zone, not as consistent; histograms
drop consistently.

He did cumulative distribution graph
Only 70% of queries get answered within 4 seconds.

NSD on signed zones, more consistent, but can't do
10M zones.

CDF says similar cutoff for NSD; does a bit better.

BIND performance  is stable for all sizes of signed
 zones
Some degredation at higher sized zones.

BIND performance issue;
only with NSEC; no problems with NSEC3

Only with a zone like the root which is likely to
have a large number of glue owner names that
get sorted between non-glue

Only for a larger (ie 100K TLD) root zone

Plenty of time until this fix will really be needed
in production.

shows example problematic zone...linear search that
wasn't optimized as well.

Task 3; start and reload times
how does nameserver startup and reload vary over
zone file size.

Above 100k, takes noticeable load time; same
for reload time.

With 32G, they couldn't do a reload for BIND on 10M
signed file

Again, proportional to zone file size.

bandwidth transfer size vs size on disk
the cases below the 100% mark are NSD; it does
name compresson in transfers, whereas BIND doesn't.
For zone transfers of signed zones, takes much more
bandwidth than doing simple rsync.

zone transfers take much longer in face of packet loss.

TCP usage
to what extent will DNSSec increase TCP at roots?

Current root zone became signed, looked at number
of TCP retries; 0.3% of requests.

Then they re-ran it with 1M TLDs in it,
again rate of truncation increases

response sizes, truncated vs non-truncated;
EDNS512 vs larger EDNS size
650, 700, most was a bit more than 800.


Root servers can expect about an order of magnitude
increas in queries per second.
A.root will go from 5/sec to 50/sec
increasing number of TLDs apears to increase TCP
traffic

https://www.dns-oarc.net/files/rzaia/rzaia_report.pdf

or email them at the addresses on the slides.


Manish Karir, PE-ARP--port enhanced ARP for
IPv4 address sharing.

Can we put ARP to more use?
Address the notion of what an endpoint identifier
is; is it IP address, or MAC address?

Looming IPv4 exhaustion
IPv6 adoption is ramping up, but how long is enough?
IPv4->CIDR->NAT-today->exhaustion->IPv6
moving from era of plenty to exhaustion
what can we squeeze more utility out of?
question long-standing ideas, scavenge more.

Range of valid source ports; 65k; largely unused.
at most, a few hundred used.

end stations have 2 unique IDs; a MAC address
and an IP.  Can we use MAC as unique ID, and
share IPs?
It's the application/service that needs it, not
the host itself.
Can you hand single IP to multiple hosts if you
limit port ranges?

What needs to change on end host, on local
network, in ARP tables, and support to find
services on the network.

PE-ARP components are on end host.
port range management on end hosts.
DHCP modified to hand ranges back.
ARP protocol needs to be modified for getting
 port numbers in requests/responses
Modified ARP table; in additional to MAC to IP,
 need port info in it as well
Need DNS service for service location when port
 number is part of reply.
SRV records are exactly what is needed in this
case.

testbed:
All 3 nodes share same IP, with limited port ranges.
outbound packets work, and internal cluster
communications also work.

Outbound is easy, it just has a smaller range of
source ports.

Inbound traffic does both IP address and port
range lookup;
running prototype on linux 2.6.29 kernel
Mostly arp changes, some routing, forwarding code,
to look at the port info coming in.
works well in both directions, both scenarios,

How to deploy this?
router on the network edge: modified ARP on linux
router kernel forwarding packets between interfaces
Bridge solution.

Don't rely on anyone else to get better utilization
out of your IP ranges.
Incremental deployment
E2E consistency--still there
Breaks one to one mapping of IP to ARP
Single IP address can be shared thousands of times.

Related work:
CIDR
NAT
CGN-NAT++
Port scavaging resolution:

conclusion: PE-ARP does break things based on old
assumptions.

It can buy more time for transitions

Packets are not modified once they leave the end
host.


Scott Liebrand, Internap
Sounds like openWRTg access point could be tweaked to
do this;
A: Yes, it's on the map to do it; currently, just for
Linux kernel, but it's definitely doable!




PEERING BOF:
We have virtual martin in the room with us!

If you haven't registered for the peering forum,
register now--and if you've register, you can
re-register again.

It's at the Ford House--follow the red light, just past
TGIFridays--might be buses here.

Your reasons for being here are unique, there are two
microphones here; try to get the mic before you ask
your question.

First peering meeting for him was 3 years ago,
it's amazing what can happen in 3 years.

Keep the discussion going--if we run over, we'll
impinge on our drinking time.

IPv4 peering personals (and IPv4 IPv6 dual-stack)

Airstream:
nmc at wins.net
CHE and MIN he's in peeringdb, AS11796
eyeballs.

Egecast: AS 15133 peering at edgecast.com,
content/CDN network
100G network, open

Stacy Hugehs
nuspeering at neustar.biz AS12008
DNS provider, small but mighty!

kloch at carpathiahost.com
Carpathia hosting AS 29748
about 500G today, looking for AP, LA peers
No backbone today; if you're in LA, ASH, it may
be good to talk to him.
Selective; would like to see a few hundred megs of
traffic between us.


Crossconnects questions and futures.
Do you pre-wire your gear to panels?  Does it help?
Is there a need for LC crossconnect support?
What about MTP? (from greg's presentation this morning)
Is crossconnect delivery getting better?
  is polarity correct?
  do you get light readings when handed over
How well do you manage your inventory of crossconnects?

Most people don't prewire, it turns out.  It doesn't
help that much, and often has to be re-done anyhow.

What about LC cross-connects; will people only do
SC handoffs, or are more and more LC cross connects
getting run?
You can't field-terminate LCs; small, difficult.
SC terminations can be done with c-core kits on site.

If you replace stock panel, you can do SC panels with
good density, and then you can get SC to LC patches.

Field techs, every time they touch LC panels, everything
gets messed around it.  :/

What about MTP?
You'll never get MTP field-terminated; so you'll never
see cross connects over MTP; too hard to do it on
custom length cables.
Look at how fast VSR cables died off.

You can't flip polarity on LC easily, either!

Mike Hughes notes that if you flood wire, it's
a short patch lead at each end; keeps the wiring
mess minimized.
At the end, it's up to you to patch it into your
gear; you provide patch hood.

Is cross-connect delivery getting better?
Yes, but polarity is often wrong.
With no light, it's a 50/50 guess on the facility
people's end.
If you leave light on, they can give light readings
on the fiber.
They often can't see the fiber at either end.

In order to prevent the NOC from getting lots of
alerts during turnups, some people leave the port
down until the cross connect is done, to limit the
errors from flapping.

Photonic switch providers, can they monitor light
levels for customers?  They can, but don't.
Different optics have different thresholds, though.

How well do you manage your inventory of cross
connects?
 Nobody has the full on database.
 Database that is mostly up to date.
 Database has some data, but is not very complete.
 If they have issues, they'll open a ticket
 Know they have cross connects, but that's it.


Igor, peering at yahoo-inc.com AS10310
content heavy, peeringDB is updated with all v6
addresses.

Scott Liebrand, Internap, AS22212
similar to igor; get sessions up, build it and they
will come.  PeeringDB is now up to date

Guy Tal, LimeLight, AS22822  peering at llnw.com
CDN, had v6 up for 4 months now; AMSIX for EU networks,
rolling out across all exchanges, and will do PNIs.
PeeringDB needs to be updated, but will be soon.

Owen DeLong HE.net, peering at he.net, AS6939
Yes, they do peer, it's an open peering policy,
even for Telia and Cogent.
And yes, they baked a cake for Cogent to try
to get them to turn peering up; there's pictures
to prove it, everyone in the room has seen it.  :D

IX Updates and News
Terremark, Josh Snowhorn
 Bogota is growing strong.
 ISTIX, Istanbul IX, turkish traffic, ME traffic
   come show up!
 NOTA, 200G there, they have F10 switches, need to
  upgrade.  Looking for new switches there
Cara Mascini, AMS-IX, they have the new MPLS/VPLS platform
 about 25 new members since last NANOG, 340 members,
 about 600 ports, half 10G, Over 1000 ports active
 Traffic is over 800G, 2G of IPv6 traffic.
 New site, interaxion, is in build up, need interswitch
  links, and then it'll be live.
 New web site, new member portal going live in a few
  weeks; new pricing for 2010 on website.
 General meeting, Nov 18th, talk to her about specifics.
Mike Hughes, LINX, he waves to Martin
 Also on Slough, not just London--diverse from docklands
 now 10 sites total, 3 non-docklands sites.  better
 resilience.
 THW facility will be 20,000 meters opening next year
  Brocade and Extereme still, will be 15 in november.
 They still have lots of 10/100 ports.
Equinix, Eric Bell--3 regions, 12 metros,
 globally hit about 380G, traffic continues to grow;
 Exascale deployed in DC, now switches in DC5 as well
 as DC2.
 MPLPP, their version of route server, could be a
 solution for HE and cogent for v6.  :D
 Hong Kong, opened new exchange
 Telehouse 2, 2Gigs there
 Looking to build requirements to expand into certain
  metros; how do they expand?
Greg, Switch and Data--he joined 20 days ago
 Peter has H1N1 unfortunately.
 Customer1 portal, all the way on right
 aggregate traffic across sites
 peer-finder tool (who you peer/don't peer with)
 participant list
 mailing lists for each metro site; portal has a
  sign-up site, it's moderated list.
 held advisory council meeting, got input, aiming
 roadmap for next year; route servers and route
  collectors getting rolled out; peer with them, helps
  them figure out who is up, who is down.
  Nov 23, Jan 3rd, network moratorium over holidays
Michael Lucking, Telx
 releasing new peering portal next week; will have way
 to interface and interact with other peers
 Everyone on switch will have access to it.
 About 20% of customers are doing IPv6, it's growing;
  not much traffic there yet.
SIX, Patrick Gilmore, gone through changes as of late;
 added Nexus 5020, have 8x10GE between main switch and
 Nexus, with 7G on it; come peer, help fill it up.
 Did renumbering, v6 was instant
 v4 not so instant; 3 stragglers who still haven't
 renumbered.  Did not buy space off Bill Manning.
 was a lot less painful than people thought; don't
 fear renumbering.
 133 AS active, 45G active.  Price drop!
 $5k for 10G port, plus optic, then free thereafter.
TOR-IX, Jon
 120 peers now, 5 years ago at 2G, today it's at 20G
 averages 15-20 peers a year joining.
 72 FE ports, 34 gig ports, 10 multigig, and 6 10G
 port, and 1 20G port.
 IPv4 and IPv6 on route server
 portal is great, works on mobile devices
Arnold Nipper from DECIX,
 still an ethernet switch.  IPv6 is 300 customers.
 lots of eastern europe, biggest location for
 eastern european traffic.
 Changed pricing model, simplified it,
 GE down to 500EU, 3rd interaxtion site at frankfurt 5
  later this year.
Marice Dean, France-IX--initiative in Paris, to try
 to consolidate existing exchanges there; 11 or 12
 active exchanges there.
 Exchanges are free to use, but you get what you
 pay for.
 Trying to build metro fabric to extend to interesting
 locations there.
 There's a lot of fiber that drops near there, but not
 much interconnection.
  Started negotiations with existing ISPs
  designed something, working to deploy it.
 First effort was to get a logo; always the most
  important bit.
 Launch date, Dec 15th, French NOG in Paris
  setting up legal structure, non profit interest group
  and working to turn stuff up.
 Slide showing first 8 nodes goes up.  Fibers with DWDM.
 Force10 switches.
 info at france-ix.fr
 Not still free.  Cost for ports will be designed to
  create a surplus for re-investment into future.
  will track other exchanges, including 100Mb ports for
   free
 Do they want to consolidate all exchanges?
 Long tail of locations, provide easy migration path out
  of.  Will launch with 120 participants.
 Started as group of individuals,
Shintaro Kojima AS7521, JPNAP, IIJ and NTT primary
 Also Tokyo major ICP and IXP investor.
 70 v4 customers plus 30 v6 customers
 traffic today is about 30Gb Tokyo and 50Gb in Osaka
 Also Equinix in Tokyo in and Osaka
 Customer ports available.  Switches will look at
  optic power for customers as well.
 No route servers yet.  So, nothing really new this
 time, hope for better updates next NANOG.

Innovation at peeringDB from RAS.
 he wrote it, people seem to be using it.
 nothing to unveil yet.  working on a wide variety of
 things.  Aiming for total re-write, but preserve
 existing data.
 Looking for a couple more admins; current workload
 for peering DB is rising; Patrick is doing most of
  it and is looking burned out.  If you're into
  masochism, and want to answer lots of email, let
  him know, let people take a break.
 Hopefully soon, will be cool innovations.

Maurice now has standing policy that in order to
 peer with Google, you have to have a peeringDB
 entry.  ME and AP folks having trouble registering.
 They feel they're not getting responded to.  Could
 be challenges getting approvals for accounts.
 The interface is only in English, it might be something
 that Google could help with translating for them.
Patrick was on vacation in China for 3 weeks, so he's
 behind.

This project that we started as a freebie in the
community needs more support.  There's challenges
to taking money for the project.

Translation--they don't get too many requests
from people about getting other languages
supported.  If someone wants to volunteer to
regionalize the pages during the rewrite, then
they'll see if they can feed it in.

There's several people helping out; Randy Epstein
from host.net, Terry R, and some other admins like
Josh that are never around.

What's the criteria for being an admin?  Patrick
and RAS have a religious stance of it being 100%
agnostic; must be objective store of data you put
in it.  Has to be someone who has the same level
of belief and won't abuse the trust.

Send email to admin at peeringdb.com if you'd like to
help out with admin role.
What is workload like?  Many hands make light work;
many emails a day.  Right now, a couple of hours
a day.

Please be as clear as possible when doing clear
 text requests; 30% is people leaving roles,
 mergers, acquisitions, etc; no indication of
 who represents a given company.
If you've got skills in detecting issues with
 people's peering knowledge, you can help out.

Why do people have 13 peeringDB accounts?
Why not have role accounts?  Will have a limit
on how many people can have accounts on the system.

If you send a request in for a change for ownership
in system, if you want someone else's record changed,
have documentation to back it up.

Closing moments; final Q&A?

Mail questions to nanog47 at corbe.tt

AS20144--administrated by ICANN, DNS admin team,
for root server; live at 10G at 3 locations, v4 and v6,
looking for 2 more sites.  Need to expand Europe
footprint, looking to see if he can get transport
services.  DNSSec is coming, nobody knows how the
traffic will grow; before root is sign, l.root will
be signed first, they want to make sure there's
enough capacity to make sure it'll work.
Open peering policy!

Joe notes everyone should vote; the whole voting
population is less than room count.

That's it, see you in austin!



OK, back down to Grand ballroom for the ARIN
open policy hour.

They fire it off at 1805 hours Pacific time.

Preview of draft policies on agenda

policy experience report will get moved to Thursday

Policy Proposal BoF
 your time
 recent list discussions

Leslie Nobile, a few items from PPML list, NANOG
list, and other places, and will solicit some
feedback from the room on those.

Anything that we want to bring to the mics?
Nothing from anyone so far.

Preview first, then BoF proper.

Draft policy review
5 on agenda for this week.
not for discussion at this BoF
 please read them, if you haven't already
 have staff and legal review
 draft policies have been on public list
 will be presented at full meeting.
Don't talk about them tonight, save it for the
 list or tomorrow!

Policy development process, flow chart are in it
as well.

2009-3: Global proposal
 allocation of IPv4 blocks to RIRs
been submitted to all 5 RIRs; must be accepted
by all 5 RIRs, and then ICANN board will review
and adopt.
All 5 RIRs have it; this is the ARIN version.
Right now, RIR can go to IANA, show what they
use, and they get get more, usually 1 or 2 /8s.
Once there's no more IANA /8s in free pool.
At that point, RIRs return IPv4 space to IANA
when they get it back to build new free pool
Once every 6 months, RIR can ask for 1/10th of
free pool as allocation.


2009-5: multiple discrete networks
allow IPv6 initial and subsequent requests for discrete,
 independent networks
/32 for ISPs, /48s for end users (and larger)

2009-6: Global: IANA policy for allocation of ASN blocks
 to RIRs.
Right now, 2 pools; 16bit and 32bit
as one pool gets lower, they can go to IANA and request
more of that type.
After Jan 1, 2010, all RIRs will be locked into same
pool; will have to show usage of all ASNs before
getting more.
This would extend ability to get ASNs of each type
 for one more year.
 Submitted to all 5 RIRs.


2009-7: Open access to IPv6
 removes to rules for initial allocation
 removes requirement to advertise single aggregate
 allocation
 remove requirement to be a known ISP in ARIN region
 or to have plane to make 200 assignments in 5 years.

2009-8: equitable IPv4 runout
slows distribution of IPv4 space
ISPs that come to ARIN, and that have been members for
 a year, can request a 12 month supply.
This would reduce supply period based on how many
available /8s IANA has left.
At 20 /8s, goes down to 6 months supply.
At 10 /8s, everyone stuck with 3 month need.

Sets maximium prefix size based on ARINs free pool;
 1/4 of ARIN's free pool, rounded down.

Read the summaries, draft policies, staff assessments,
etc, come to meetings prepared to discuss them.


Now, on to Policy BoF

Informal setting
 presentation of ideas
 discussion and feedback
(5 minutes total)

No committments at this time!

Going forward
your choice:
 do nothing
 continue discussions informally
 take the discussion to PPML
 submit a policy proposal.


So...that's the rules--who has something to talk about?

Remote participation is allowed too...but nobody's
in the room.

Lee Howard, TWC, ARIN board of trustees, the trustees
not allowed to propose, so he's just breaking the ice.

Some discussion during NANOG portion of week;
routing considerations around ARIN policies.
Should ARIN policies take into consideration any
routing considerations?


Dani from PeakWeb
The precedent from IPv4 side is that ARIN doesn't
guarantee routing; it just does registration
services.
That's really where it needs to be.
We're smarter now, we need to take the language
out.
Not enough of us were really watching when the
2bit to 4bit ASNs transition happened; we need
to start getting involved sooner, and speak up
earlier in the process.
We need to focus on proper sizing of allocations,
and let business determine usage.
In IPv4 world, we were trying to deaggregate
class Bs...it eventually worked its way out
in IPv4 world, it'll be able to work its way
out in IPv6 if we let it.

Jason Schiller, Verizon; ARIN is chartered to
shape policy; and policies will shape routing
decisions.  If ARIN starts allocating /30s,
they may not guarantee routability, but once
ARIN starts giving them out, and one ISP
routes them, the pressure will be there for
everyone to route them.
It's useful to be able to take ARIN policy back
to help sell best practices inside your company.

Jon, Internet society
If we're walking in the space of a policy that
will be discussed later...the transfer policy
was difficult for the panelists to understand;
they had to call in lawyers to try to interpret
it.
That kind of feedback from NANOG panelists doesn't
fit with the 3 goals of ARIN.
Clear, technically sound, and useful.

The routing policy question--obligation of ARIN
and other RIRs that they not just conserve scarce
resource, but conserve slots in the routing table
which is a shared commons, globally.  There will
be more discussion of economics during the week.
The tragedy of the commons is well known, and is
well documented; there's economic incentive for
each, but if it happens unbounded, the commons
get destroyed, and they all die.
The global routing table is a global commons;
adding to it will be in the interests of every
individual network access provider.
There is an obligation to preserve slots in the
global routing table...

Aggregation is a goal in the number resource
model, but it's not a criteria.

Cathy Aaronson--irony of statement.
The aggregate part in statement was to preserve
global routing table slots.  That was the intent
at the time.

John Curran, president, CEO of ARIN.
The incorporation and bylaws are wide-reaching,
and talk about technical coordination, which is
very vast.  There are things tied to number allocation
which are in NRPM, but talk about visibility of
information in whois.
the ability to abide by NRPM can be used to decide if
people get new resources, or get to keep existing
resources.
If this group wants to govern what goes into the
routing table, it can go in.
But the community needs to decide if that's a space
we get involved in adding and enforcing via the NRPM.
We can put constraints on routing in NRPM, like we
do with whois visibility.  It's up to us.

Ed Kern--he'd love to have it in the policy to make
Jason to route all the /30s.  :D  The v6 allocation
was BCP in the policy strategy.  It should be taken
out now, and moved to a BCP status.  IETF and ITU
aren't the right forums for this.

Leo Bicknell, ARIN advisory council
we have the discussions repeatedly.  The numbers
agency and network operators exist in symbiotic
relationship; the numbers are needed for routing,
and without routing, there's no need for number
resource registration.
As with any symbiotic relationship, both parties
need to understand the other's needs; both sides
need to keep the other healthy.
ARIN community needs to understand the limitations
of routers and policies that operators are using.
It is not useful for ARIN community to dictate to
operators how to configure their devices...in
general.
Operators need to understand implications of
policy on a 50 year span, not just next year.
Provide useful information on when routers are
likely to fall over back to policy team.
More information sharing, and less dictating
needs to happen.

Dave Farmer, ARIN AC.
Everyone needs to chill out just a little bit.
It's your routers, your policies, yes.
But you have to let ARIN know what policies
make routing policies possible.
It wouldn't be possible to be able to take /48s
for critical infrastructure if it didn't come
from one little corner.
"For this piece of stuff, this is what you can do"
ARIN needs to assign numbers in a reasonable fashion
to allow operators to make decisions around the
numbers.
The ability we have to write policies stems from
ARIN's allocations of addresses in a coherent fashion.

Cathy again.
She's super-excited that people noticed the IPv6
allocation policy, since it's been there for 10
years!  finally, people are looking!
When they went from /19 to /20, they put notes
in saying they were going to look at routing
tables, and retract if it caused too much pain.

Lee Howard--delighted with feedback to that
topic of conversation.  People need to send
email indicating the words to arin.ppml at arin.net;
if you don't know how to write the words, they
will help you write the words.  Their job is
to help you write clear, concise, useful words.
And vote for him on Friday!


New topic from Cathy
Something for ARIN to answer; with v6 allocations, they
are not being sparsely allocated, they are consecutively
being allocated.  Is this on purpose?

A: yes, it's on purpose.  No sparse allocation in v6.
Only 1 RIR is doing sparse, that's APNIC.
They do need to discuss it, John is nodding, they
will discuss it but have not done it yet.


Doni again
Question about if ARIN wants to move from consecutive
to sparse, is that policy based, or can ARIN just
move to do that internally?
A: ARIN can do that internally; Dave Conrad notes that
the initial goal was to use sparse allocation, so it
is a goal, but also a work in progress.

Leah Roberts, ARIN AC
Increment between them could be bumped up before moving
to sparse allocations; could it be moved up a few bits
to a nibble boundry at least?  /29 doesn't map very
well.

Anything else from community members, policy-wise?

Martin Hannigan
Recovery; should we revisit it today?
it's becoming aparent there will be 2 internets out
there; you'll need both addresses for quite some
time.  There will be a market for v4 addresses;
it would be better to see it be rational and fair.
There's operators, policy, and there are shareholders
as well.  Some want to be good, but others have to
keep the economy going, and get our paycheck.
We'll probably see /28s on the internet so v4 can still
'grow' while the move to v6 trundles along.
How do we manage /8s locally, not just under global
policy.

Scott Liebrand
There have been several policies to take baby steps
along the path--what suggestions does he have for
moving in that direction?

Martin replies:
Bite off the low hanging fruit--just define what it
is.  Stragglers, things out there that aren't in
routing table, no valid contacts, etc.
We've had a mishmash, but no coherent plan.
This needs to not be tied into other policies.
Needs to strictly be about reclamation.  Start
low, and then move to high stuff.

Lee Howard
you said recovery a few times; do you mean recovery
of IPv4 unused or underused space?
Unused is very different from underused.
We don't have any policy about underuse of space;
you need to have minimal use to get *more* space.

NRPR section 12--John Curran notes that you should
read the manual; he looks at it many times, and
comes away shaking.  Policy provides ARIN the
necessary tool to do a few things:
it's up to ARIN staff organization to use that
policy; they use it now for addresses that are
not legitimately held by anyone at all.
They can prevent unheld resources from being held
by a party.
If that's low hanging fruit, as it is brought
to ARIN, ARIN is attempting to make sure they don't
get legitimized by ARIN updating records.  But that's
reactive based on suspicious requests coming in.
Other case is resources that aren't being used,
but are legitimately held, even if it's not being
used, never routed, etc.
Those unused or heavily underutilized resources
are *not* being touched right now.  They have a
legacy RSA agreement, that once signed, prevents
ARIN from ever doing anything with that block.

So, no legitimate holder they can catch.   But
the ones with legitimate holders, they cannnot
both offer a legacy RSA, and simultaneously
move against those resources.

To move against resources, we need to resolve that
against legacy RSA agreements.

300 RSA signers, but that covers more than 25% of
the legacy space; so there's more and more coverage
of that space; once signed, they're part of the
system, and by contract, they is no method to
do reclamation on that space.

If we're going to change the legacy RSA, he needs
to know now!

Chris Grundeman, TWC
There was a policy after last meeting, 2008-7, enacted
after last meeting, the intention was to help identify
the fallow space.  The tool will be there to help
identify it for reclamation.

Owen DeLong, HE.net
section 12 para 5 attempts to reconcile issues;
ARIN can reclaim space allocated by ARIN for
under use when legacy RSA is signed.

Leo Bicknell--the legacy space is mired in issues.
non-legacy space, RSA states that if ARIN believes
the space is not being used for the original purpose,
you may need to re-justify it, and if it cannot be
justified, ARIN may reclaim it.

John: they go after such resources *when* they come
to ARIN and attention is drawn to them.  They have
reviewed and revoked resources based on that, but
they are not going out and looking for space that
would fall under those terms.
Most reporting to ARIN is under fraud reporting
process.  It only is used if people feel that
fraudulent claims are made to ARIN in the application
process; any other legal issues are *not* moved on.

John, ISOC
Low hanging fruit may still be on tree because it is
rotten.  APNIC talks about audit trails for space that
is recovered.  If you reallocate it to someone, and it
turns it is ACL'd off or blacklisted for places they
need to reach, they are not better off for getting
the space.
When space is recovered, can its history go with the
block, so that potential recipients know what they
are getting.

Leslie Nobile notes that space reclaimed through various
means is held for 1 full year, and they use RBLs, checking
140 RBLs and lists, and noting that it has been fallow
for a year; they attempt to ensure they are issuing
clean space as much as possible.  they are very aware
of this, it's not a policy, but it's an internal
proceedure.

Martin
policies and procedures are great, perhaps if ARIN
could wave the flag and let us know, that would be
great.

There's some low-hanging fruit that isn't caught
by the policies; if you're the POC, and the company
went bankrupt, it's really easy for POC to just hold
onto the space.
He thinks there's some low hanging fruit we may be
stepped on.

Also, legacy /8s getting returned need a local, non
global policy to handle them.

XXX from Jamaica, covers issues around ICT,
learning a lot at ARIN meeting.
Reading mission statement up on wall, a question
to the staff and community.
How do you draw line between a watchdog or deal
with issues, when one main activity is to facilitate
the advancement of Internet while outreach and
education is a primary goal.
It seems the Internet is such a huge monster, it
needs this broad-based consensus at all times.
The issues are overwhelming, the v4 to v6 migration
needs even more education and outreach around it.
She's learning a lot, and hopes ARIN can help
educate even more about how these issues can be
addressed and handled in the Carribean region.

We're out of time; it's a few minutes after seven.

Beer and pizza party up in rotunda, first elevator
on the left, runs from 7pm to 9pm.

Thanks to everyone who brought questions to the
microphone today!!



More information about the NANOG mailing list