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@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@wins.net CHE and MIN he's in peeringdb, AS11796 eyeballs. Egecast: AS 15133 peering@edgecast.com, content/CDN network 100G network, open Stacy Hugehs nuspeering@neustar.biz AS12008 DNS provider, small but mighty! kloch@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@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@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@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@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@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@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@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@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!!