Latest Operations Minutes from Michael

Minutes from the LHCONE Operations call June 3, 2013

Operational procedures and reporting issues on the LHCONE.
-       Discussion of recent investigations
 
1) The University of Nebraska Lincoln (UNL) observed an apparent LHCONE issue and in reporting it sent mail to lhcone-operations@cern.ch which in it’s conception is for discussing operations rather than reporting issues. The process agreed to on the call and at prior face to face meetings was to work through your LHCONE NSP to report problems, however we also agreed that this was not clearly stated.
 
The other operational issue related to the Cisco 6500 switch donated by FNAL to the LHCONE collaboration. This device has been of great value in supporting the rapid deployment of the overlay network. However supporting its’ operational model presents a challenge since it is controlled by an end site rather than an NSP and it’s existence in the path is not apparent using in band tools such as traceroute. This issue needs to be discussed further and we will look to add it to the Paris meeting in some form.
 
Action items related to the operational process:
-   Update the Cern wiki to instruct sites to contact their LHCONE Network Service Provider to report service issues.
-    Investigate the option of restricting email to the lhcone-operations mailer in order to eliminate confusion.
 
2) Request for information regarding LHCONE implementations at Tier 2&3 sites, case studies, lessons learned. Our new sites continue to have issues when connecting initially, more useful technical information is necessary regarding what works and how it is implemented.
-   Mike O'Connor would like to contact Tier 2&3 sites to collect useful information by discussing their implementation and connection experience. Please send email to moc@es.net with LHCONE in the subject.
 
3) Proposal to share LHCONE flow data in order to gain a more comprehensive understanding of the traffic on the LHCONE to feed the planning and policy definition process. Issues raised were, netflow standard and non-standard variations, synchronizing timestamps, sample rate etc.  The idea was interesting if theses issues could be effectively addressed without having to expend a vast amount of resources to develop it.

Submitted by David Foster on Wed, 06/05/2013 - 10:18