In order to enable an iCal export link, your account needs to have an API key created. This key enables other applications to access data from within Indico even when you are neither using nor logged into the Indico system yourself with the link provided. Once created, you can manage your key at any time by going to 'My Profile' and looking under the tab entitled 'HTTP API'. Further information about HTTP API keys can be found in the Indico documentation.
Additionally to having an API key associated with your account, exporting private event information requires the usage of a persistent signature. This enables API URLs which do not expire after a few minutes so while the setting is active, anyone in possession of the link provided can access the information. Due to this, it is extremely important that you keep these links private and for your use only. If you think someone else may have acquired access to a link using this key in the future, you must immediately create a new key pair on the 'My Profile' page under the 'HTTP API' and update the iCalendar links afterwards.
Permanent link for public information only:
Permanent link for all public and protected information:
BNL and FNAL primary links now 2x8.5Gbps
RAL 10G backup link will be ready in 2/3 months.
PIC backup link now on a different path inside the Geant network.
New Computer centre building. Some issue, now sorted out.
The second 10G link for LHCOPN will be delivered in 2/3 months.
Currently design the next generation network architecture.
Current network: SuperJANET5 until 2013.
Services: JANET IP (40G core), JANET Lightpath (Ethernet over MPLS), JANET Aurora (dark fibre research platform)
Positive 100G trials with Nortel and Ciena
RAL: using the Netsight of Janet, Cacti at the site (weathermap), Scrutinizer (commercial, sflow netflow)
KIT: ping, nagios, Netview (sends email and sms), Cacti (BGP monitoring), Netflow (Cisco product), Syslog
NL-T1: Nagios, Cacti, PHP-Syslog-NG, Rancid, Remedy. BGP monitored by Nagios. Availability: ping from nagios.
CNAF: MRTG(traffic) NAgios (status availability and alarms), Netflow analyzer Pro,
CERN: spectrum (commercial, link status and stats), Nagios (BGP
NDGF: Nagios, ZINO (home maded, link status, BGP), sierra (home made sflow collector) Alcatel and Ciena NMS.
IN2P3: Cricket for statistics, smokeping (remote hosts), Netsurv (home made)
PIC: Cacti, Nagios (BGP, interfaces)
FNAL: Nagios, Cisco IP SLA, RoutePlotter (traceroute and RTT changes monitoring) Netflow analysys.
ESnet: Spectrum (devices, links, LSPs. Main tools for the NOC). E2EMON (but not used becaouse slower in reporting)
USLHCnet: Monalisa (weathermap, link status and availability, topology chnages, send alarms), Perfsonar-PS (feeds E2emon)
Who is using perfsonar MDM:
CNAF is using the MDM to check the network is able to run 1G data transfer between T1-T1.
KIT: No, only checking it displays correct information
CNAF: yes: data transfers, hades, weathermap, OWD, traceroute
PIC: no, especially because the backup link cannot be added. Would like to have jumbo support.
Should be only a measurement system, not alarming/monitoring
Who are the users? Application managers, network engineers.
Twiki not updated
Integrate or tickets in the the standard GGUS system? Pro and cons.
No email interface to ggus will be implemented.
Support may be reduce after the end of EGEE.
We need a SLD and monitoring.
ENOC after EGEE
EGEE ends April 2010, EGI should follow. Only 0.5 FTE for networking is foreseen.
LHCOPN operations support will be followed by IN2P3
GGUS TTS support, included LHCOPN part, is moved to WLCG
Installing perfsonar-ps in many US T2s and T3s.
Large installed base.
ESnet on US tier2s
A increase of traffic between US T2s and European T1s is foreseen. Dedicated links would be better than using the generic IP connectivity as today.
NL-T1: access to raw data not very useful. status map accessible to all users via grid certificate.
KIT: BGP route checks for change of paths, data transfers.
PIC: E2Emon would be useful. Perfsonar is useful to show the link is not the problem. Not interested in row data. Weather map access should be open.
NDGF: Wish access to raw data. No use of e2emon
FNAL: have measurements, notifications, weathermap for end users, should be service based monitoring and not link based
CNAF: it's useful, access to raw data may be interesting in the future, nagios plug-in for notifications, weather map can be interesting if is very reliable. e2emon is used for debugging.
RAL: as FNAL
IN2P3: performace test important, may not interested in alarms, e2emon is not in use because unreliable.
CERN: perfromannce test, traceroute, alarm, decouple e2emon.
Service level definition
Define response time
How to measure: link capacity, BER
John: Complete the SLD
TbD: Take Responsibility for Operations
John: Lead the Operational Conference Calls
Guillaume: follow up GGUS integrations of LHCOPN tickets.
MonWG: define requirments for perfsonar and provide it to Geant.
Next meeting 28-29 June 2010 in Barcelona
Thanks to JANET for hosting the event and for the dinner.