<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Gentlepeople,<div><span class="Apple-tab-span" style="white-space:pre">        </span>Below are the detailed notes that Geert Jan took from Monday's meeting. I've edited them a bit, but any errors are mine, not GJ's. Many thanks for his OCD attention to detail ;-)</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre">        </span>- Jim</div><div><br></div><div>---<br><br><span class="Apple-tab-span" style="white-space: pre; ">        </span><span class="Apple-tab-span" style="white-space: pre; ">        </span>Minutes IETF78 NOC conf call<br><span class="Apple-tab-span" style="white-space: pre; ">        </span><span class="Apple-tab-span" style="white-space: pre; ">        </span>Jun 28 2010, 17:00 UTC<br><br>Attendees:<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Randy<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Chris<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Rob/Alice<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Lucy<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Jim<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>John kemp</div><div><span class="Apple-tab-span" style="white-space:pre">        </span>Karen<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>geertj (scribe)<br><br>1. Contact info<br>jim:<span class="Apple-tab-span" style="white-space: pre; ">        </span>Please send contact info, arrival date/time, route to Jim,&nbsp;<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>for coordination and &nbsp;initial contact, even if it's your intention to get a local SIM</div><div><br>2. NOC room<br>jim:&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>As on ietf78-techs, Marcia wants room 0.11 as 9th breakout room.<br>&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>Can we use 2 rooms (0.6:Madrid, 0.7:Lisbon) instead.&nbsp;<br>&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>They are smaller and, more important, 2 rooms,&nbsp;<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>NOC team can't sit together.<br>geertj: these rooms only have 4 outlets each and they terminate in SER3.<br>&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>If we do this, we should move servers to SER1,&nbsp;<br>&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>better as SER1 has airco anyway.&nbsp;<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>See my mail about Euro Centre and Foyer today.<br>jim/randy: 2 rooms not good for coordination.&nbsp;<br>&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>We already have 3 native language groups in NOC team, one group that<br>&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>knows each other inside out, chances are we'll end up with different<br>&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>groups, not good for cooperation.<br>jim:&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>What about fiber connectivity? geertj: has asked Sven,&nbsp;<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>will probably get response tomorrow<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>ACTION: geertj to get info on SER7 fiber connectivity.<br>randy: &nbsp;we don't want to hurt Marcia by not giving up 0.11.<br><br>We'll wait for a. information to arrive, b. things to crystal out,<br>Jim will talk to Marcia about options.<br><br><br>3. Equipment<br>chris:&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>working on list, working with morgan.<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>jim: &nbsp;pls coordinate with AMS folk<br>geertj: what about extra equipment because of changes&nbsp;<br>&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>(e.g. pending NOC change). jim: ship extra<br>jim:&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>what % of kit are we shipping? chris: 70%, we have extra 3750's.<br>jim:<span class="Apple-tab-span" style="white-space: pre; ">        </span>chris+geertj to coordinate equipment list offline after conf call.<br>jim:&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>lean towards more equipment to allow for eventualities.<br>jim:&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>what about patch cords? Joel: will het from Verilan.<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>ACTION: Jim to verify availability<br>jim:<span class="Apple-tab-span" style="white-space: pre; ">        </span>ext routers, see my mail about two M7i's<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>geertj: will you use both simultaniously or have one spare<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>jim: will use both routers, one to terminate each fiber link<br>geertj: confused because while the M7i's have redundant power supply,<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>the 3560E's do not. Chris: will use 2 switches on each location,<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>and spread AP load among them so if one fails, every other AP will<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>go down.</div><div>[Jim's Edit: There is a dual switch core (stack of 3750's), but the leaf switches are all single switches. If possible, we'll do link aggregation from each of the core switches to each leaf switch]</div><div><br></div><div>jim:&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>tape order? joel: 15.7 pounds, goes to secretariat because of weight,<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>should be shipped, not carried.<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>People have responded to question about label makers,&nbsp;<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>people should bring, joel has tape<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Joel has usual supply of cable ties, velcro, crimper, cable ends<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Who will bring spool of Cat5E?<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>ACTION: geertj to order 1000ft spool of cat5 (Dijkhoff electrotechniek),<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>to be delivered directly at MECC.<br>joel:&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>will go through equipment list<br>all:<span class="Apple-tab-span" style="white-space: pre; ">        </span>tools. jim, joel, geertj will bring.<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>geertj only arriving wed evening, not a problem.<br><br><br>4. External connectivity<br>jim:<span class="Apple-tab-span" style="white-space: pre; ">        </span>Verilan (actually, belgacom) is still announcing 130.129.0.0/16,<br><br><br>5. Design<br>jim:<span class="Apple-tab-span" style="white-space: pre; ">        </span>We'll use the same design as last summer (Stockholm),&nbsp;<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>same IP's, VLANs, but with admission control added.&nbsp;<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Will use existing Stockholm VMware images. &nbsp;<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>ACTION: jim to publish revised design somewhere coming weekend.<br><br>6. Budget<br>jim:<span class="Apple-tab-span" style="white-space: pre; ">        </span>There is no budget yet, should have happened.&nbsp;<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>What costs will we have?<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>- travel<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>- shipping<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>- misc onsite<br>geertj:<span class="Apple-tab-span" style="white-space: pre; ">        </span>budget SER1 power? geertj and chris to ask for price,&nbsp;<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>and order, power SER1. We need this<br><br><br>7. Service VMs<br>jim:<span class="Apple-tab-span" style="white-space: pre; ">        </span>As said earlier, /16 is still hot<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>this should have stopped but ICANN had difficulties.<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>We need the space to connect our VMware machines to Internet.<br>chris:<span class="Apple-tab-span" style="white-space: pre; ">        </span>asked RIPE to NAT-in the IP space so we could log in,<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>but didn't get response yet.<br>??:<span class="Apple-tab-span" style="white-space: pre; ">        </span>please ask RIPE explicietly<br>geertj: why not announce 130.129.0.0/17 and 130.129.128.0/17<br>??:<span class="Apple-tab-span" style="white-space: pre; ">        </span>why do we want this? to light up our VM's and configure them.<br>jim:<span class="Apple-tab-span" style="white-space: pre; ">        </span>while begacom is still announcing, there are no issues with us<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>re-claiming the space this way as the address space is no longer<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>used by them<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>ACTION: jim to chase verilan/belgacom to stop announcing the space.<br><br><br>8. power MDF<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>ACTION: chris / geertj to handle offline<br><br><br>9. verilan<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>what about powercords?<br>geertj:<span class="Apple-tab-span" style="white-space: pre; ">        </span>caution, Belgian cords may not work in Netherlands, they're different<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>ACTION: chis + geertj to coordinate offline<br><br><br>10 printers<br>joel:<span class="Apple-tab-span" style="white-space: pre; ">        </span>Choices are to ask RIPE NCC, or buy local (discardable) printer.<br>geertj:<span class="Apple-tab-span" style="white-space: pre; ">        </span>what's the volume?&nbsp;<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>- term room: several thousand sheets.<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>- secretariat uses pre-printed packs but needs to print<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>&nbsp;&nbsp;receipts and late badges.<br>joel:&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>suggest one printer term room, one secretariat<br><br><br>11. power strips/UPS<br>jim:<span class="Apple-tab-span" style="white-space: pre; ">        </span>for breakout rooms: handled by Marcia, she'll work with MECC&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span><br><span class="Apple-tab-span" style="white-space: pre; ">        </span>on this.<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>for NOC: &lt; 10 strips, verilan or geertj<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>ACTION: geertj to bring strips<br>geertj:<span class="Apple-tab-span" style="white-space: pre; ">        </span>do we need UPS?<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Consensus is we do not need UPS.<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>geertj will buy NOC team beer if he gave poor advice.<br><br>12. admission control<br>jim:&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>lots of messages:<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>- We need network admission control for Beijing IETF<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>- IPv6 not optional, network must work for IPv6<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>&nbsp;&nbsp;(though initial access portal can be IPv4-only,<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>&nbsp;&nbsp;as long as people have IPv6 conn afterwards.<br>john:<span class="Apple-tab-span" style="white-space: pre; ">        </span>one possibility is to use large squid proxy w/ access control<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>all: this is web only, hence not acceptable.<br><br><span class="Apple-tab-span" style="white-space: pre; ">        </span>A long discussion follows. We plan to do 2 options:<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>- WPA2/enterprise for those clients that can<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>- access portal (and open network) for those clients that cannot,<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>&nbsp;&nbsp;this is for interop with older clients.<br><br><span class="Apple-tab-span" style="white-space: pre; ">        </span>People will do WPA2 if possible. This is desirable: it removes<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>load from portal solution.<br><br><span class="Apple-tab-span" style="white-space: pre; ">        </span>How do we do portal? john:<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>- do cisco switches, will have performance issues<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>- do linux MAC filter bridge box for performance,<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>&nbsp;&nbsp;probably also performance issues.<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Suggests to use capabilities of Cisco CAM for access control.<br><br>rob:<span class="Apple-tab-span" style="white-space: pre; ">        </span>Performance (with large # clients) is problem.<br><br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Does Juniper have solution?<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Are we developing something new? Why?</div><div>[Jim's Edit: Rob was commenting that the Juniper EX switches have an embedded portal. However, because it's both device dependent and there's no guarantee that we'll have them available in Beijing, it was rejected]<br><br>rob:&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>2000(v4) + 2000(v6) CAM entries<br><br><span class="Apple-tab-span" style="white-space: pre; ">        </span>We'll have 4 ssids: IETF, IETFa, 802.1X, 802.1Xa</div><div><br></div><div>[Jim's Edit: likely named differently .... something like ietf-portal, ietf-portal-a, ietf.1x, ietf-a.1x ... we should reserve ietf and ietf-a for the open net]</div><div><br><br><span class="Apple-tab-span" style="white-space: pre; ">        </span>How about captivator?&nbsp;<br><span class="Apple-tab-span" style="white-space: pre; ">        </span><a href="http://net.doit.wisc.edu/~dwcarder/captivator/">http://net.doit.wisc.edu/~dwcarder/captivator/</a><br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Let's setup and try - it's been used in networks<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>a lot larger than IETF.<br><br>jim:&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>are you (john) OK with captivator? john: no experience<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>is wej (author captivator) part of noc team? yes</div><div><br></div><div>[Jim's Note: wej isn't the author of Captivator, but works directly with him]<br><br>randy:&nbsp;<span class="Apple-tab-span" style="white-space: pre; ">        </span>SO, we'll have 2 access paths: WPA2, and captivator/portal.<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Will they do to border router separately? probably yes,<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>though there are multiple options.<br><span class="Apple-tab-span" style="white-space: pre; ">        </span><br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Will we have single mac per token?<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>chris: radius can spec max# sessions per token,&nbsp;<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>suggest &lt; 5<br><br>randy:<span class="Apple-tab-span" style="white-space: pre; ">        </span>for beijing, token number must not be sequential,<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>must not be guessable</div><div><br></div><div>[Jim's Note: This came up in today's admin call ... we'll have to work with the secretariat to see if we can work up something better for Beijing]</div><div><br><br><span class="Apple-tab-span" style="white-space: pre; ">        </span>will non-auth people have access to internal network only? yes<br><br>lucy:<span class="Apple-tab-span" style="white-space: pre; ">        </span>don't use email for token ident - will never fly on ietf list<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>also legal issues (at least in EU).<br><br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Plan is: there is no free net w/o auth in maastricht,<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>we want to TEST this before Beijing.<br><br><span class="Apple-tab-span" style="white-space: pre; ">        </span>We will have no open IETF SSID unless there is a panic.<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>It will be configured, but SSID will be shut down unless we hit<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>a fatal problem and there is panic<br><br><span class="Apple-tab-span" style="white-space: pre; ">        </span>username: regid-on-badge<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>password: ietf78<br><br>geertj:<span class="Apple-tab-span" style="white-space: pre; ">        </span>why not just hand out random strings for everybody, not just<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>for privacy fetishists and/or people with lots of devices?<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>A: the load on registration desk will kill AMSL staff,<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>so we want this to be the exception.<br><br>geertj:<span class="Apple-tab-span" style="white-space: pre; ">        </span>in bejing, will people be able to get anon papers or do they<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>need to be registered (privacy et all)?&nbsp;<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>A: secretariat to decide, we only build tech solution.</div><div><br></div><div>[Jim's Note: Just to clarify, the secretariat isn't the authority here. It will be decided by the IETF Chair (Russ) and the IAD (Ray) after advisement]<br><br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Will we use WPA1?<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>pro: will offload more people, very little add config, low risk<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>con: Russ asked not to do this<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>WPA1 is more secure than portal, and we do this for admission control,<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>not for confidentiality. If WPA2 w/o crypto would exist, then<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>we would have used that instead!</div><div><br></div><div>[JIm's Note: My take on the conclusion here is that we'll socialize &nbsp;WPA1/WPA2. If Russ objects, we'll make it WPA2 only. The goal is to draw off as many users as possible onto WPA, so more broadly accessible is better.]</div><div><br><br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Do we need need dedicated hardware for captivator box?&nbsp;<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>If it is an inline bridge then VMware box won't cut it.<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>ACTION: Jim to ask RIPE for extra hardware.<br><br></div><div>[Jim's Note: I will do so ASAP, but I'm waiting on wej's estimation on the hardware requirements]</div><div><br><span class="Apple-tab-span" style="white-space: pre; ">        </span>Also see Randy's message after conf call, who very nicely<br><span class="Apple-tab-span" style="white-space: pre; ">        </span>sums up what we'll want to have.<br></div></body></html>