[01:00:43] Jelte joins the room [01:01:53] Jelte leaves the room [01:02:12] arifumi joins the room [01:02:24] ops, this room isnt used today ? [01:04:07] ggm joins the room [01:04:15] Joe Abley on signing the root [01:04:27] same process as at present, DoC NTIA still applies [01:04:38] (previous slides, openness/transparency in processes re-affirmed) [01:04:51] Verisign will manage ZSK, NTIA authorized changes [01:04:59] structure diagram of workflow. [01:05:27] http://iepg.org/2009-11-ietf76/rootsign-ietf76-iepg.pdf [01:05:45] 7 tier security model to protect the KSK [01:06:14] GSM secured locked rooms, cabinets, smartcards, HSMs. individually locked boxes [01:06:21] based on physical security used by commercial CA [01:06:33] DPS: the DNS version of an X509 CPS [01:06:50] proposed by .SE registry in Stockholm IETF [01:07:36] DPS used to tie entities to each other in policy term [01:09:05] bringing third parties into the public role [01:10:07] RFC5011. [01:10:22] roll on 2-5 [01:10:29] no intention to roll without warning. [01:10:31] using SHA256 [01:10:44] new codepoints. [01:10:53] requires s/w upgrade. seen as a feature by many [01:11:13] KSK 2048, ZSK 1024 using SHA256/NSEC not NSEC3. [01:11:23] RRSIGS 15 day validity, resign on 10 day cycle. [01:11:35] other RRSIGs 7 days, regen 2x day. [01:11:49] key ceremonies. performed with expected roll [01:11:53] zsk will be done quarterly [01:12:04] pre-generated, pre-signed at previous ceremony. [01:12:13] sign bundles, give to verisign, allow them to operate for a quarter [01:12:21] gives contingency time. window of operations [01:12:33] Root trust anchor. [01:13:24] also publish as CSR to make it easier for some systems [01:13:39] roll out planned in 'incremental' fashion [01:13:45] natural conservitism over change at root. [01:13:59] when signed, responses received by resolvers, larger than today [01:14:13] (the dnssec ok bit, DO bit being set, enables this to happen) [01:14:33] Simon Perreault joins the room [01:14:55] possible large responses will cause some roots to go dark, for some clients. possible. [01:15:08] want to be able to roll back. [01:15:28] removing security info would make it insecure. so if relying on it, will see it 'go away' [01:15:36] to avoid this, avoid buildup of community expecting it to be signed [01:15:41] the responses will be large, can measure [01:15:55] so signing key will be different to apex. [01:15:58] impossible to validate [01:16:07] at end of rollout, rollover, new key can validate [01:16:21] timeline. [01:16:24] sign Dec 1. [01:16:32] internal use. [01:16:41] Jan start individual letters in root will serve [01:16:50] L first [01:16:55] up to july, others added. [01:17:00] by july, all roots serve signed [01:17:13] jul1 2010 KSK roll, zone becomes validatable, fully deployed [01:17:18] docs [01:17:24] high level arch posted at ntia [01:17:29] (see PDF for url) [01:17:37] DPS in drafting, will be posted RSN [01:18:02] feedback requested from ops, experts. root-dnssec-feedback@verisignlabs.com [01:18:33] Joao: DoC. emergency rollover during pubhol [01:18:48] Joe. already mechanism for emergency changes. cannot propagate instantly, TTL/cache, but there is a 24/7 number [01:18:59] already provision for IANA to contact DoC out of hours, to process things [01:19:01] verisign is 24/7 [01:19:15] it might take more than minutes but not an entire long weekend [01:19:17] bhoeneis joins the room [01:19:19] Richard Lamb [01:19:38] wed 3pm, castle view one. real issues/qs, nitty-gritty, problems, come and chat [01:19:48] room castle view #1 [01:19:57] Next we have RIPE LABS [01:20:03] (no slides) [01:20:03] fujiwara joins the room [01:20:57] Mirjam Kuehne and Robert Kisteleki [01:23:21] jlcJohn joins the room [01:23:28] anybody knows slides will be uploaded or not ? [01:23:29] Web site, but also community Research results, new ideas, tools [01:23:35] I am sure Geoff will do this Asap. [01:23:53] playground, platform to test [01:23:57] prototypes [01:24:00] comments function, forums [01:24:37] (slides are on joao's laptop will be posted after talk) [01:25:15] need to register but its easy [01:25:25] conversation between individuals [01:25:32] on the other side, no guarantees quality/service levels [01:26:05] if tool, idea, suggestion gets support more likely to develop [01:26:15] number of things on site, robert to show. [01:26:21] shane kerr posted tool [01:26:40] lots of data, movies [01:27:22] working on things with community to publish after this meeting [01:27:27] labs@ripe.net or mir@ripe.net [01:27:37] gets eyeballs on the site! [01:27:54] hands to robert for show [01:28:33] yone joins the room [01:28:34] can be research results, data, tools. scope is .. wide [01:28:46] Robert now presents samples of RIPE labs contents [01:29:40] INRDB. Internet Number Resource Database [01:30:03] large storage/retrieval system across large amounts of internet number related data [01:30:13] unified apps, don't care where data is coming from. [01:30:24] holds all 10 years of RIS data in quick query fashion [01:30:37] ꈲ joins the room [01:30:55] the movie of the racetrack [01:31:13] how resources allocated to the RIRs [01:31:48] So, who won ? [01:31:54] graphical representation of how fast RIR allocate resources [01:32:05] Ole 'do they everr crash?' (laughter) [01:32:33] movie of history of address deployment, status. [01:32:46] colours encode status of INR, routed, allocated etc [01:32:56] shows how RIR receive resources, how fast into routing system [01:33:18] shows debogon process [01:33:25] backed by INRDB. covers 5 years [01:33:32] were able to superimpose routing onto allocation [01:33:44] now discussing 'resource explainer' [01:33:48] or REX for short [01:34:00] (btw, if out of room, feedback on audio is useful) [01:34:24] currently, if want to look up routing go to RIS, routeviews, then go alloc db, then geolocate.. all disparate [01:34:30] build service, all info in one comprehensive way [01:34:58] now showing live [01:35:49] gih joins the room [01:38:08] showing live system, fetch of data from sources, graphing [01:38:52] ꈲ leaves the room [01:39:18] RIPE engineer wanted more/less specifics, so added tool to do that easily [01:39:20] one-click [01:39:36] 'who is responsible' [01:39:46] queries back to find IANA->RIR->entity delegations [01:39:54] graphs of IANA view of delegation [01:40:10] shows gaps in data, eg including historical gaps in data. [01:40:18] asks for IANA data. [01:40:21] Marshall: lost? [01:40:26] Robert Asked, not able to provide [01:40:33] Bert: I have complete data [01:41:22] shows WHOIS fetch [01:41:29] bias to RIPE data, richer information source [01:41:36] do what they can, in consultation with other RIR [01:41:46] shows change over time [01:41:52] maintainer movements over time. [01:42:14] shows reverse-DNS [01:43:12] network activity using CAIDA datya [01:43:57] ripe labs talk is http://iepg.org/2009-11-ietf76/RIPE-Labs-IETF76-mir.pdf [01:44:10] black lists. [01:44:17] UCE/spam resource lists are included [01:44:51] geolocation. using GEOIP/Maxmind public data [01:45:22] highlighting issues for example with Kroot [01:46:56] showing geolocation for anycast [01:47:44] showing other roots [01:49:19] show M root host status [01:49:40] shows google, new /16 [01:49:56] shows routing by other AS, invisible in routing system (randy would observe doesn't mean anything) [01:50:10] google started announcement, then announce smaller chunk [01:50:51] shows the IP behind sourceforge, thinkgeek, slashdot [01:51:06] reverse-DNS, adds perspective, allows grouping [01:51:30] floor comment 'another evil empire' [01:51:52] shows ISP in holland, geolocate to NL [01:52:11] but drill into city level, you can see much more fine grained routing [01:54:13] go to ripe labs, try the tool [01:54:29] planning to add more. ASN and Ipv6 support [01:54:57] specialized reports for different users: law enforcement different to hostmaster [01:55:18] what do you want? try it out. let us know. give feedback. [01:56:12] 'its not magic' -summarizing information out there. giving service to customer base [01:56:25] heaps of re-processing. terabyte of data. talk offline [01:56:33] INRDB is on 5 servers, off-the-shelf [01:56:56] Danny McPherson. enumerate more specifics. useful. augment [01:57:13] Robert yes, have student in science group, thesis will be to extend bgplay [01:57:17] historical bgplay [01:57:46] when IPv6 support? [01:57:54] team working on it. roll out before end of year [01:58:45] next is Vijay Gill [01:58:48] no slides at this time [01:59:07] Google infrastructure and how applications and networks are being built [01:59:18] realities of large-scale distributed systems [01:59:20] findings from the field [01:59:38] eburger joins the room [02:00:17] the key learning is 'worse is better' -ops 'lite' approach [02:00:33] keep the network simple, just a lot of it. [02:00:47] good quote about sheepishly following fads in programming [02:00:57] stuff promoted is too hard. key learning in google [02:01:08] important not to be all things to all people [02:01:16] 6 easy, 7 requre thought [02:01:20] 8 is worse [02:02:08] dont build just for its own sake [02:02:59] rhe joins the room [02:03:09] larissas joins the room [02:03:11] orange joins the room [02:03:46] scale issues [02:04:17] substantial proportion of data has to be kept in ram. crawl 10tb an hour. youtube is 24h new vide per minute [02:04:23] try to keep everything under 300ms response time [02:04:51] 80% of costing in data centre is electricity. server build was able to half energy footprint [02:05:06] $30 per server per year savings [02:05:13] nothing is ever going to have a KB. [02:05:22] marshall [02:05:38] modest server improvement? [02:05:54] vijay no its two parts, IT equipment and network equipment. its a sum (you need to see slides to get this) [02:06:22] fan power costs! [02:06:39] Jaap Akkerhuis joins the room [02:06:54] minimise energy by linear programming in real time [02:07:04] data ctre photos [02:07:21] using recycled water [02:07:35] cluster diagram. from machine to rack to cluster [02:07:54] storage hierarchy [02:08:27] some content is similar to http://www.cs.cornell.edu/projects/ladis2009/talks/dean-keynote-ladis2009.pdf [02:08:55] (ie may be useful. I don't mean VJ is plagiarising, I mean its the info which is in the same space) [02:08:57] larissas leaves the room [02:09:15] how big is a petabyte. 1500Lbs of 1TB drives [02:09:24] Q: rack disk vs data centre disk [02:09:36] A: disk is within rack, or within the data centre. where it is, to be accessed [02:09:45] Amdhal's law variant. [02:10:00] converging performance on cores. building large bladeservers doesn't seem to buy anything [02:10:12] 100,000+ cores, blades don't make any difference [02:10:17] comms overhead dominates [02:10:20] once over 10,000 [02:10:35] reliability/avail stats [02:10:41] things will crash, have to deal with it [02:10:54] even with MTBF 30 years, once you hve 10,000 one will fail per day [02:11:01] s/w has to be fault tolerant [02:11:45] even built racks using ebay sourced crap ram, if s/w is fault tolerant can cope with it [02:11:52] 1-5% of disks will die [02:12:08] server will crash at least twice (2-4% rate) [02:12:15] Q: soft errors in memory.. A: will talk to later [02:12:23] Q: power when failed? [02:12:25] A: turn them off [02:12:33] internet not 5-nines. [02:12:46] sharks, dead horses, theives, .. drunken hunter effects [02:13:03] photo of powerline for pacnorthwest. covered with ice. [02:13:13] hunters with alcohol + rifles. dangerous to fibre [02:13:19] they shoot the insulators. [02:13:47] collateral damage. shoot down other bits, bolts, fibre MRL inside google, tracks requests for power. asking for u/g path before hunting season in oregon [02:13:49] (laughs) [02:14:14] shows repair kit being tracked in to fix fibre, fusion splicer. couldn't get skiddoo in. had to ski in [02:14:33] IOWA data centre resilient fibre, traintrack-flood.. fibre suffers (photo) [02:14:50] fibre laid around tracks, special bogie digs side of track, lays fibre 3ft down [02:15:06] when have goods train derail, bogies cut fibre. becomes large fibre plough [02:15:21] fibre on gas is safe. backhoe at gas, you die [02:15:43] strong incentive to be safe around gas pipes. 10:1 mbtf compared to rail fibre [02:15:49] real h/w stats . [02:15:56] 0.5 machiens will overheat [02:16:09] 1pdu failure. 1000 machines disappear, 6hrs to come back [02:16:18] 1 rack move. (planned) [02:16:25] 1 network rewire. (coincident oftenly) [02:16:38] 20 rack failures (40-80 machines, 1-6hrs to fix) [02:16:43] racks go wonky (5) [02:16:47] 8 net maint [02:16:51] 12 router reloads [02:16:56] 1000 machines [02:16:58] thats in 1 year. [02:17:00] pretty crappy [02:17:10] graph of data failure. [02:17:25] 1.6disk fails across a petabyte (6hrs) [02:17:36] no correlation btween manuf. and disk type [02:17:39] what fails are batches [02:17:53] buying 5 seagate, 5 fujitsu bought at same time [02:17:55] 2 fail in 30 min [02:18:02] failure correlates to batches, not type [02:18:09] server/consumer have same failure rate in field [02:18:20] only 20% more expensive in server disk $ buy price [02:18:27] design for drives to fail [02:18:41] monitor systems with permanent offline storage on health, map/reduce [02:19:21] warehouse sized data centre photo [02:19:24] cooling tower grids. [02:19:36] power sub next to building (there are two) [02:19:49] ex-aluminium smelter site: lots of cheap power [02:20:02] 20% of elec. bill is transmission cost. better to be close to power, hydro, nuke [02:20:05] dam is just off photo [02:20:18] why not called a data center? [02:20:45] data center is heterogeneous [02:20:57] partition, manage separate, facility.computer has no shared knowledge or build [02:21:15] warehouse scale: central pool, common design. integrated facility [02:21:23] everyone (most) program on top of same platform [02:21:32] few get special cases, in general, everything runs on same primitives [02:21:48] energy cost breakdown as pie chart [02:21:55] 30% of energy is DRAM [02:21:58] 10% disk [02:22:01] 33% cpu [02:22:08] network 5% other(*server) 22% [02:22:17] breakdown by centre [02:22:21] UPS 18 [02:22:24] chiller 33 [02:22:27] crac 9 [02:22:29] it 309 [02:22:32] it 30% [02:22:34] (sorry) [02:22:36] PDU 5 [02:22:39] tx 1 [02:22:40] lighting 1 [02:22:44] want to run without chillers [02:22:51] when you have an excursion, cannot reject heat. [02:22:58] have to turn on heat pipe, cannot turn on if don't have. [02:23:00] then have to load shed [02:23:05] migrate jobs away from data ctre [02:23:11] or kill for a few hours [02:23:16] Q: assume things will fail, why UPS? [02:23:25] A: build into servers themselves [02:23:34] not centralized. batteries in servers [02:23:40] last long enough to get gens up [02:23:53] want un-correlated faulure. without UPS get strong correlation [02:24:31] large scale systems [02:24:45] single search touches 1k machines in 0.25sec [02:24:53] 36 data centres 800k servers [02:24:55] 40 servers/rack [02:25:00] 200 goog FS clusters [02:25:24] map reduce over time [02:25:50] (mike problems) [02:26:15] spanner design goals [02:26:19] million-10million machines [02:26:29] deslgn rules [02:26:47] app splits diagram [02:27:01] showing characteristics, where latency comes in, archive storage needs [02:27:09] network reqts [02:27:17] no oversubscribed links within cluster very important [02:27:22] fine grained failoure domains [02:27:36] fan-in problem. queen bee/worker protocols [02:27:51] queen needs to be better connected. if oversubscribed, loose hundreds of worker machines will go dark [02:28:05] lower latency doesnt matter as much. cut through swithcihg not so important [02:28:14] but if can do it, can use cpu on one box, ram on another [02:28:29] make optimal network domain as large as possible, 100,000 hosts 10g connected no oversold [02:28:47] ask for more than you need. but this leads to under subscription, costs rise [02:29:03] cluster. 4gps between racks [02:29:15] dream cluster is 512-1m cores, 8-16-32 core per machine [02:29:23] 16-32gb per machine memory per cor [02:29:26] 10Gbs [02:30:35] PS. Hiring people who replaces broken server machines? ;) [02:30:47] yes [02:30:53] Vijay says he is hiring [02:31:30] So fascinating job. [02:31:31] Q how cascade racks [02:31:34] A cannot go into more detail [02:31:50] about 100,000 machines connected in one non-blocking 10g system. thats the goal [02:32:01] Q multiple aps. [02:32:03] how divvy up? [02:32:10] or build data for app? [02:32:11] they probably have clusters of customer-grade linksys routers [02:32:12] A: in general do not [02:32:21] some specialized [02:32:25] share ram in special ways [02:32:31] but for everything else, can share [02:32:44] job control schedules, arranges [02:32:55] UPS built on servers [02:32:57] built on back [02:32:59] A yes [02:33:34] Marshall: graph with lines. time to fix was 6hrs [02:33:36] time to get onsite? [02:33:40] A no. we have onsite [02:33:54] sometimes problem is to get 'there' [02:33:59] have onsite, pull from inventory [02:34:02] go to where servers [02:34:04] rewire [02:34:08] mechanical work, time to get to rack dominates [02:34:21] 3am has paging costs [02:34:24] don't tend to page. [02:34:29] if loose rack, no big deal, wait to morning. [02:34:33] average time takes 6hrs [02:34:36] during day, 30min fix [02:35:07] now we have Geoff Huston http://iepg.org/2009-11-ietf76/2009-11-08-stateless.pdf [02:35:41] IEPG expert in useless tools [02:35:47] and also bad ideas [02:35:56] challenge: start with really bad idea, figure if turn into code [02:36:01] uselessly bad idea in code, at same time [02:36:10] networks 101. there is tcp, there is udp [02:36:26] use tcp for reliable, stop-goback-checkum [02:36:29] bum in the wind: run udp [02:36:35] every datagram is an adventure [02:36:42] then network 102. [02:36:43] client-server [02:36:47] talks limitations [02:36:54] issues fly around [02:37:00] connection is a block of memory [02:37:02] the 5 tuple [02:37:05] connection intensity [02:37:18] cannot recycle identifiers until old user has died, packets disappear. used to be 6min [02:37:19] even now its 2 [02:37:22] its time. [02:37:30] BGP. any long-held session has reset attack [02:37:39] aim 3rd party reset right seqence, 'goes bang' [02:37:44] fake SYN [02:37:47] otoh UDP also sucks [02:37:53] large UDP frags. difficult [02:38:09] the frags don't have port header. all the rest are 'just IP' so firewalls drop [02:38:12] need frag handler. [02:38:24] kinda ok in V4. can frag on fly. v6 purists said 'not on the fly' [02:38:38] send back ICMP too big. [02:38:44] ASHIDA joins the room [02:38:47] go back to massive DNSSEC responses. (joes talk) [02:38:59] what if use V6, dnssec, UDP. and path MTU smaller than 1/f MTU [02:39:04] going to get V6 packet too big. [02:39:06] what do? nothing! [02:39:15] problem. [02:39:19] use UDP. answer from hell [02:39:24] TCP seg reassembly is hell too [02:39:30] bad idea factory. lets cross the beams [02:39:39] UDP with TCP segmentation re-assembly [02:39:45] lets go on, you think its ok (laugh) [02:39:55] client runs conventional TCP. has no clue. standard. [02:40:00] but server runs 'udp' stateless. [02:40:03] stateless TCP. [02:40:07] how to do it? [02:40:10] look at TCP trans [02:40:17] (time series explaing SYN/ACK flows) [02:40:41] server does RESP+FIN [02:40:49] client does its side. ACK of FIN [02:40:57] may get more response, might get flow control [02:41:00] basic set just simple [02:41:03] from Server PoV [02:41:06] when get syn send syn-ack [02:41:12] flip src,dst, ports. [02:41:17] stateless: who cares about sequence numbers [02:41:22] use time (laughs for 666) [02:41:24] offer MSS. [02:41:35] offer reasonable MSS to get query. 1220 [02:41:39] all other TCP opts waste of time [02:41:49] when get req. send ack. [02:41:57] start seq and gen resp. [02:42:01] be a little bit naughty [02:42:03] no path mtu [02:42:14] dice responce to 512units, get thtough anuythin [02:42:19] assemble packet train, send fyn. done. [02:42:21] no flow control [02:42:24] when get fin send ack [02:42:31] ignore all else [02:42:38] can it be done? [02:42:39] yes. [02:42:44] FreeBSD. gets in the way [02:42:46] not kernel hacker [02:43:01] how to write raw sockets. capture raw packet. use TCPDUMP. using libpcap [02:43:06] can see raw packet [02:43:09] writing? [02:43:19] use raw socket interface. tell kernel you handle all IP headers. [02:43:30] tiny font C code [02:43:43] to get around tcp, get pcap for input, raw sockets for output [02:43:44] does it work [02:43:51] same dump, (tcpdump) [02:43:57] backend figured out answer [02:44:17] gen asnwer, send back to client [02:44:19] then shutdown [02:44:40] want lunacy. client thinks its doing TCP. server, lightweight stateless talks UDP [02:44:47] run stateless TCP on resolver [02:44:57] only had a week, avoided bind [02:45:02] wrote a shim layer [02:45:13] client thinks talking to tcp. talking stateless, stateless server is udp to real dns [02:46:05] whats it good for? [02:46:09] nothing! (laughs) [02:46:21] Has Geoff thought of going into business selling WAN acceleration products? [02:46:23] but worried about tx, big packets, worried about state, then, can do this lunacy [02:46:45] frag assmbly badly handled at IP level. firewalls don't hand frags [02:46:52] V6 got in the way, handling of large UDP disastrous [02:47:05] if streaming, constant UDP. icmp makes sense [02:47:44] third mutant cousin asked to tea-party [02:47:46] ill mannered bad idea [02:48:03] three good books to read [02:48:18] tcp/ip illustrated. unix networks (stevens) tcpdum pdocs Van Jacobsen et all [02:48:26] can run. http://www.potaroo.net/tools/useless [02:49:10] marshall. used libpcap to do trickery. involves CPU. will drop packets. system won't but won't go to cpu level [02:49:17] A; this is crap [02:49:23] ASHIDA leaves the room: Replaced by new connection [02:49:24] ASHIDA joins the room [02:49:24] it has no capacity. not production solution [02:49:28] if want to go fast, write into kernel [02:49:33] takes longer than a weekend [02:49:47] Q: tcp has state, to be reliable [02:49:50] but drops [02:49:55] A and? [02:50:00] client.. sends ack. [02:50:11] server doesn't care. [02:50:17] client will ack ack ack ack ack (boring) reset [02:50:20] doesn't matter [02:50:21] will time out [02:50:26] shane [02:50:35] does matter. pushing state from auth server into recursive. [02:50:38] a: pushing outward [02:50:48] shane but client is usually recursive resolver [02:50:54] don't want state on server. [02:51:08] a: what can that guy do,… run [02:51:17] shane but if install, .. [02:51:21] a: arguing a bad idea. [02:51:40] such a bad idea, thought of before [02:51:43] 1644, ttcp. [02:51:51] A: no, subtly differnt. trying to be too nice. [02:51:56] this is far worse. this is really bad. [02:52:07] merge nasty things, eg data with syn [02:52:11] wanted to send response with fin [02:52:15] not worried about the handshake [02:52:19] don't care if client got the data [02:52:37] Q have need. address [humm] ship [02:52:49] ASHIDA leaves the room [02:53:10] Lixia Zhang presents http://iepg.org/2009-11-ietf76/FA-IETF76.pdf [02:53:13] FIB compression [02:53:24] sorry FIB aggregation [02:54:05] reduce fib size. idea has been around for a while [02:54:47] claimed advantages [02:54:58] larissas joins the room [02:55:05] no impact on forward, no routing proto change, compatible with other changes [02:55:13] (lisp, APT, agg etc) [02:55:49] bje joins the room [02:55:51] costs. CPU processing time. extra routing space costs [02:56:27] depends on level of agg [02:57:24] looking at FA effectiveness [02:57:31] opportunistic [02:57:37] eg how many exit points on west coast? [02:57:46] prefixes alloc to same economy [02:57:50] share next-hop [02:58:57] orange leaves the room: Replaced by new connection [02:59:30] orange joins the room [03:00:36] level 1 agg. remove covered prefixes. [03:00:56] no new prefixes introduced, nothing previously unreachable now reachable [03:01:57] second level. a few /17s share prefix, aggregatable. combine but routable space remains the same [03:02:14] level 3. agg non-siblings. not numerically adjacent [03:03:17] level 4, allow holes in the nexthop [03:03:48] Q is this NP complete generically? [03:03:55] computationally difficult? [03:04:00] Lixia no, pretty easy [03:04:16] 2 algs, being done by students see paper cited in slidepack [03:04:46] eval methodology [03:04:58] BGP routing tables, updates from oregon routeviews [03:05:13] assume prefix with same next-as-hop share next-ip-hop [03:05:31] verified 85%->93% or better in data (see paper) [03:05:38] compute on linux [03:05:57] patricia trie rib/fib [03:06:52] compare relative processing time [03:07:07] indicative [03:07:23] slide of compression outcomes for each level [03:07:37] edge gets more than core [03:08:01] eburger leaves the room [03:08:20] rhs is tier 1s eg level3 [03:08:41] compress 300,000 to 10% [03:08:43] near edge [03:10:01] what does ratio mean? [03:10:12] can get quite a few more years of lifetime if fib size is issue [03:10:26] computation time [03:10:42] even level4 is 100ms constant. 4b, variant cost scheme [03:10:51] up to 400ms peaks [03:10:57] not optimised [03:11:19] extra routable space into fib table. [03:11:23] now can be reachable. [03:12:15] handling routing updates [03:13:00] incrementally update agg FIB [03:13:50] small % of pfx have lots of updates [03:13:55] just exclude if know who are [03:14:51] how frequently? [03:16:22] bhoeneis leaves the room [03:16:40] 7x month can work for the demonstrated compression 100k to 150k growth [03:17:23] for large ISPs, least aggregatable, 30-70% compression possible [03:17:29] FA computation overhead looks feasible [03:17:46] need access to routing tables to compare. can compress even more [03:17:51] seeking data to work on [03:18:08] papers in PDF pack, drafts coming [03:18:17] look at incremental algs [03:18:33] (Q from floor) [03:18:54] withdraw propagation [03:19:05] lixia. if withdraw shorter, just have to expose longers [03:19:27] Q then receive update, could do all on fly maintain smaller size all the time [03:19:29] less painful [03:20:34] incurs multiple changes to fib [03:20:50] will look [03:21:03] Q extra routable addr space. most impl have notion of route points to nexthop drop [03:21:14] insert in holes, undoables. semantically do what had before [03:21:18] does requre entry [03:21:54] next we have Stephen morris on http://iepg.org/2009-11-ietf76/OpenDNSSEC.pdf [03:24:07] "push the button we do the rest" model of dnssec [03:24:35] ASHIDA joins the room [03:24:42] tools lacking [03:24:49] neet h/w accel [03:25:09] nominet, spoken to registrars [03:25:18] ins-and-outs of DNSSEC. they panic [03:25:33] want install/start and forget systems [03:25:47] they guarantee success. we can install in registries, but we're only part of the chain [03:25:56] dnssec needs to be installed at end-user sites to be useful [03:26:02] list of particiapnts [03:26:30] s/w developers, registries, consultants [03:26:49] opendnssec. simplifies processes. for one or more zones. more is important [03:27:40] open source. take, modify [03:27:45] arch, version 1 [03:28:17] policy modules [03:28:25] key and signing policy. choices made about zone [03:28:36] algs, timelines, sig lifes, nsec/nsec3 [03:29:04] working on policy editor [03:29:07] KASP enforcer [03:29:13] handles key management, rolling [03:29:25] introduce before sign, retain old after [03:29:37] "protect people from themselves" [03:29:47] generates keys as required, but won't use until confirmed keys backed up [03:30:10] HSM.. range of prices. also used for acceleration [03:30:14] use PKCS11 [03:30:42] tool to test HSMs, check they support subset needed [03:31:34] also s/w model of HSM to use [03:31:46] signer engine, enforces jitter [03:31:53] sigs expire at steady rate, keep load down [03:32:03] maintains SOA serial AND NSEC/3 chain [03:32:29] KASP auditor [03:32:32] paranoia [03:33:03] check policy being enforced [03:33:44] bump in the wire [03:34:26] Glenn Kowack joins the room [03:34:28] using KASP auditor, can stop output functions [03:34:34] can veto [03:34:46] stats [03:34:48] status [03:34:56] 1.0beta released in october [03:35:02] release aimed for late november [03:35:34] arifumi leaves the room [03:36:40] Jaap presents http://iepg.org/2009-11-ietf76/rsst-root-scaling-iepg-present.pdf [03:36:59] findings of the study. [03:37:04] requested by ICANN [03:37:31] group formed early 2009. "can we do this?" [03:37:54] SSAC/RSSAC, staff [03:38:25] 3 months work [03:39:15] TNO root scaling model. under direction (TNO like NIST) [03:40:02] new resource records for DNSSEC [03:40:04] IDNs [03:40:14] new add recs, glue for V6 [03:40:16] new gTLDs [03:40:36] implies zone becomes larger, rate of change increases. both size/volatility issues [03:41:18] interviewed all root ops [03:42:05] all done under NDA [03:42:23] only aggregated, no specifics published [03:42:55] spoke to DoC, IANA, ICANN [03:43:15] also verisign as editor [03:44:29] outreach/information gathering [03:44:52] activity was announced, input sought [03:44:58] model. [03:45:21] left has people who can make change requests (to IANA) eg tld ops [03:45:38] IANA involves NTIA, verisign in 'holy triangle' [03:46:04] when settled, changes put in distribution masters, sent to root servers, republished, anycasted. then resolvers on far RHS can see [03:46:10] the root server system [03:46:21] system highly decentralized, dynamic [03:47:12] larissas leaves the room [03:49:28] changes. [03:49:41] system is flexible, adaptable but not instantaneous [03:50:10] if changes paced, system can adapt, maintain headroom. [03:50:11] manage risk [03:50:30] ASHIDA leaves the room: Replaced by new connection [03:50:39] diagram of dynamic 'operating ranges' [03:50:56] 3-6 month timeline fits normal operational processes [03:51:06] ASHIDA joins the room [03:51:07] 12-24 month lead time needed for major upgrades [03:51:24] major re-design can take several years [03:51:57] types of stress [03:52:06] zone size itself not the problem [03:52:43] volatility is: affects volume of data passing around [03:52:46] sudden step changes [03:53:23] changes which can affect behaviours of the server [03:53:33] AAAA/DNAME/DNSSEC. records [03:53:50] handle dnssec types, increase in size, volatility. amplification issues [03:54:16] DNAME still havent been decided [03:54:27] might have different impacts on how server works [03:54:37] dnssec big step change [03:54:40] new record types [03:54:49] changes size of responses, 3-4x [03:55:34] gradual changes [03:55:54] adding more TLDs, 'more of the same' if not DNAME. [03:56:04] adding IDN the same [03:56:59] other issues [03:57:27] bje leaves the room [03:57:41] increased response sizes, query rate [03:57:50] malformed Queries [03:57:52] findings [03:58:33] provisioning [03:58:38] scaling is about human factors [03:58:55] pub side, its relying parties, poorly connected [03:59:49] graphs of impact [03:59:49] gih leaves the room [03:59:56] (I have to go. sorry) [03:59:58] ggm leaves the room [04:00:18] Simon Perreault leaves the room [04:01:08] yone leaves the room [04:01:31] rhe leaves the room [04:02:24] orange leaves the room [04:02:57] Jaap Akkerhuis leaves the room [04:04:36] Glenn Kowack leaves the room [04:09:55] jgunn joins the room [04:15:13] jlcJohn leaves the room [04:23:40] ASHIDA leaves the room [04:29:44] Jaap Akkerhuis joins the room [04:35:15] Jaap Akkerhuis leaves the room [04:57:33] gih joins the room [04:57:38] gih leaves the room [04:57:44] arifumi joins the room [04:57:47] arifumi leaves the room [05:08:32] ggm joins the room [05:11:48] jgunn leaves the room [05:24:54] ggm leaves the room [05:38:04] Jaap Akkerhuis joins the room [05:38:53] Jaap Akkerhuis leaves the room [05:52:44] fujiwara leaves the room [23:51:44] jlcJohn joins the room [23:51:52] jlcJohn leaves the room