[ietf78-tech] Notes from the Monday 6.27.2010 tech meeting

[Jim Martin]

Gentlepeople,
	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 ;-)

	- Jim

---

		Minutes IETF78 NOC conf call
		Jun 28 2010, 17:00 UTC

Attendees:
	Randy
	Chris
	Rob/Alice
	Lucy
	Jim
	John kemp
	Karen
	geertj (scribe)

1. Contact info
jim:	Please send contact info, arrival date/time, route to Jim, 
	for coordination and  initial contact, even if it's your intention to get a local SIM

2. NOC room
jim: 	As on ietf78-techs, Marcia wants room 0.11 as 9th breakout room.
 	Can we use 2 rooms (0.6:Madrid, 0.7:Lisbon) instead. 
 	They are smaller and, more important, 2 rooms, 
	NOC team can't sit together.
geertj: these rooms only have 4 outlets each and they terminate in SER3.
 	If we do this, we should move servers to SER1, 
 	better as SER1 has airco anyway. 
	See my mail about Euro Centre and Foyer today.
jim/randy: 2 rooms not good for coordination. 
 	We already have 3 native language groups in NOC team, one group that
 	knows each other inside out, chances are we'll end up with different
 	groups, not good for cooperation.
jim: 	What about fiber connectivity? geertj: has asked Sven, 
	will probably get response tomorrow
	ACTION: geertj to get info on SER7 fiber connectivity.
randy:  we don't want to hurt Marcia by not giving up 0.11.

We'll wait for a. information to arrive, b. things to crystal out,
Jim will talk to Marcia about options.


3. Equipment
chris: 	working on list, working with morgan.
	jim:  pls coordinate with AMS folk
geertj: what about extra equipment because of changes 
 	(e.g. pending NOC change). jim: ship extra
jim: 	what % of kit are we shipping? chris: 70%, we have extra 3750's.
jim:	chris+geertj to coordinate equipment list offline after conf call.
jim: 	lean towards more equipment to allow for eventualities.
jim: 	what about patch cords? Joel: will het from Verilan.
	ACTION: Jim to verify availability
jim:	ext routers, see my mail about two M7i's
	geertj: will you use both simultaniously or have one spare
	jim: will use both routers, one to terminate each fiber link
geertj: confused because while the M7i's have redundant power supply,
	the 3560E's do not. Chris: will use 2 switches on each location,
	and spread AP load among them so if one fails, every other AP will
	go down.
[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]

jim: 	tape order? joel: 15.7 pounds, goes to secretariat because of weight,
	should be shipped, not carried.
	People have responded to question about label makers, 
	people should bring, joel has tape
	Joel has usual supply of cable ties, velcro, crimper, cable ends
	Who will bring spool of Cat5E?
	ACTION: geertj to order 1000ft spool of cat5 (Dijkhoff electrotechniek),
	to be delivered directly at MECC.
joel: 	will go through equipment list
all:	tools. jim, joel, geertj will bring.
	geertj only arriving wed evening, not a problem.


4. External connectivity
jim:	Verilan (actually, belgacom) is still announcing 130.129.0.0/16,


5. Design
jim:	We'll use the same design as last summer (Stockholm), 
	same IP's, VLANs, but with admission control added. 
	Will use existing Stockholm VMware images.  
	ACTION: jim to publish revised design somewhere coming weekend.

6. Budget
jim:	There is no budget yet, should have happened. 
	What costs will we have?
	- travel
	- shipping
	- misc onsite
geertj:	budget SER1 power? geertj and chris to ask for price, 
	and order, power SER1. We need this


7. Service VMs
jim:	As said earlier, /16 is still hot
	this should have stopped but ICANN had difficulties.
	We need the space to connect our VMware machines to Internet.
chris:	asked RIPE to NAT-in the IP space so we could log in,
	but didn't get response yet.
??:	please ask RIPE explicietly
geertj: why not announce 130.129.0.0/17 and 130.129.128.0/17
??:	why do we want this? to light up our VM's and configure them.
jim:	while begacom is still announcing, there are no issues with us
	re-claiming the space this way as the address space is no longer
	used by them
	ACTION: jim to chase verilan/belgacom to stop announcing the space.


8. power MDF
	ACTION: chris / geertj to handle offline


9. verilan
	what about powercords?
geertj:	caution, Belgian cords may not work in Netherlands, they're different
	ACTION: chis + geertj to coordinate offline


10 printers
joel:	Choices are to ask RIPE NCC, or buy local (discardable) printer.
geertj:	what's the volume? 
	- term room: several thousand sheets.
	- secretariat uses pre-printed packs but needs to print
	  receipts and late badges.
joel: 	suggest one printer term room, one secretariat


11. power strips/UPS
jim:	for breakout rooms: handled by Marcia, she'll work with MECC 	
	on this.
	for NOC: < 10 strips, verilan or geertj
	ACTION: geertj to bring strips
geertj:	do we need UPS?
	Consensus is we do not need UPS.
	geertj will buy NOC team beer if he gave poor advice.

12. admission control
jim: 	lots of messages:
	- We need network admission control for Beijing IETF
	- IPv6 not optional, network must work for IPv6
	  (though initial access portal can be IPv4-only,
	  as long as people have IPv6 conn afterwards.
john:	one possibility is to use large squid proxy w/ access control
	all: this is web only, hence not acceptable.

	A long discussion follows. We plan to do 2 options:
	- WPA2/enterprise for those clients that can
	- access portal (and open network) for those clients that cannot,
	  this is for interop with older clients.

	People will do WPA2 if possible. This is desirable: it removes
	load from portal solution.

	How do we do portal? john:
	- do cisco switches, will have performance issues
	- do linux MAC filter bridge box for performance,
	  probably also performance issues.
	Suggests to use capabilities of Cisco CAM for access control.

rob:	Performance (with large # clients) is problem.

	Does Juniper have solution?
	Are we developing something new? Why?
[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]

rob: 	2000(v4) + 2000(v6) CAM entries

	We'll have 4 ssids: IETF, IETFa, 802.1X, 802.1Xa

[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]


	How about captivator? 
	http://net.doit.wisc.edu/~dwcarder/captivator/
	Let's setup and try - it's been used in networks
	a lot larger than IETF.

jim: 	are you (john) OK with captivator? john: no experience
	is wej (author captivator) part of noc team? yes

[Jim's Note: wej isn't the author of Captivator, but works directly with him]

randy: 	SO, we'll have 2 access paths: WPA2, and captivator/portal.
	Will they do to border router separately? probably yes,
	though there are multiple options.
	
	Will we have single mac per token?
	chris: radius can spec max# sessions per token, 
	suggest < 5

randy:	for beijing, token number must not be sequential,
	must not be guessable

[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]


	will non-auth people have access to internal network only? yes

lucy:	don't use email for token ident - will never fly on ietf list
	also legal issues (at least in EU).

	Plan is: there is no free net w/o auth in maastricht,
	we want to TEST this before Beijing.

	We will have no open IETF SSID unless there is a panic.
	It will be configured, but SSID will be shut down unless we hit
	a fatal problem and there is panic

	username: regid-on-badge
	password: ietf78

geertj:	why not just hand out random strings for everybody, not just
	for privacy fetishists and/or people with lots of devices?
	A: the load on registration desk will kill AMSL staff,
	so we want this to be the exception.

geertj:	in bejing, will people be able to get anon papers or do they
	need to be registered (privacy et all)? 
	A: secretariat to decide, we only build tech solution.

[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]

	Will we use WPA1?
	pro: will offload more people, very little add config, low risk
	con: Russ asked not to do this
	WPA1 is more secure than portal, and we do this for admission control,
	not for confidentiality. If WPA2 w/o crypto would exist, then
	we would have used that instead!

[JIm's Note: My take on the conclusion here is that we'll socialize  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.]


	Do we need need dedicated hardware for captivator box? 
	If it is an inline bridge then VMware box won't cut it.
	ACTION: Jim to ask RIPE for extra hardware.

[Jim's Note: I will do so ASAP, but I'm waiting on wej's estimation on the hardware requirements]

	Also see Randy's message after conf call, who very nicely
	sums up what we'll want to have.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.daedelus.com/pipermail/ietf78-tech/attachments/20100629/024e284b/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3675 bytes
Desc: not available
Url : http://www.daedelus.com/pipermail/ietf78-tech/attachments/20100629/024e284b/attachment-0001.bin