1. www.egi.eu EGI-InSPIRE RI-261323 EGI-InSPIRE www.egi.eu EGI-InSPIRE RI-261323 1 EGI Network Support task force January 24, 2011 EGI OMB f2f meeting Amsterdam EGI.eu 1 Mario Reale IGI / GARR mario.reale@garr.it

2. www.egi.eu EGI-InSPIRE RI-261323 EGI-InSPIRE www.egi.eu EGI-InSPIRE RI-261323 2 Overview Introduction to the Task Force Definition of the identified use cases Answers from the NGI

3. www.egi.eu EGI-InSPIRE RI-261323 3 Goals and duration Mandate: assessment of the current stand of Network Support for EGI and the formulation of a proposal for it –Gather user requirements from NGIs –Assess the status of the available tools –Further develop and consolidate new proposed tools –Identify missing bits / tools –Propose tools and workflows to the EGI Net Sup community –Define draft workplan for the next months Started on October 20, 2010, ended on January 21, 2011 –around 8 working weeks duration –coordinated from remote met 5 times in VideoConference: 20/10, 10/11, 22/11,10/12, 14/1 3

4. www.egi.eu EGI-InSPIRE RI-261323 4 Membership Etienne Duble France-Grille (UREC CNRS) Xavier Jeannin France-Grille (UREC CNRS) Esther Robles (RedIRIS) Alberto Escolano (RedIRIS) Bruno Hoeft (D-GRID KIT) Mario Reale (IGI GARR) Fulvio Galeazzi (IGI GARR) Alfredo Pagano (IGI GARR) Wenshui Chen (ASGC) Domenico Vicinanza (DANTE Int.Rel.Team) Szymon Trocha (PSNC/GN3 SA2 T3 PerfSONAR)

5. www.egi.eu EGI-InSPIRE RI-261323 5 What has been done Identified 7 network related Use Cases Organized a questionnaire about them for the NGIs, gathered and published the results Identified a strategy for all of them –although we specified strategies at different levels of accuracy and technical insight Some of us worked on further development of tools –PerfSONAR live-CD, HINTS, NetJobs Designed the GGUS network support workflow to be implemented for EGI Liaised with GN3 about the current PerfSONAR status/tools

6. www.egi.eu EGI-InSPIRE RI-261323 6 What has NOT been done Brought all proposed new tools to a final, frozen production status after extensive validation phase –But all proposed tools can usefully be used by early adopters Made a world-wide, general assessment of all available tools for network monitoring and network support in general Developed new tools in all cases we felt either a brand new tool or a major improvement of the existing ones would be required –Example: Network-related Scheduled Maintenances

7. www.egi.eu EGI-InSPIRE RI-261323 7 Identified Use Cases (7) Answers from the NGI Questionnaire

8. www.egi.eu EGI-InSPIRE RI-261323 8 GGUS Grid Users and Site Administrators open a ticket in the GGUS support system when they think a network issue is behind the problems they are experiencing. Tickets are assigned to the GGUS Network Support Unit and processed until solved. We need to give a home to all network related issues in EGI – currently unattended To whom assign network related issues ? –A support team made by network experts from volunteering NGIs or NRENs ? –Skip the Grid community and assign tickets directly to the NRENs and/or GEANT/DANTE ? Many parties involved in ticket processing: Site Admins, NREN NOCs and APMs, GEANT NOC and APMs

9. www.egi.eu EGI-InSPIRE RI-261323 9 Answers on GGUS Answer n.3: Having a GGUS support unit for Network Support is useful, but tickets should be handled automatically according to a given workflow and routed to NRENs/NGIs contacts; no need to have a permanent team behind this unit

10. www.egi.eu EGI-InSPIRE RI-261323 10 EGI PERT Grid Users experiencing poor performances in data transfers can refer to a global EGI PERT Contact Team (with both Grid Middleware/Applications and Network Know-How) to get support The idea would be to have EGI-wise a unique team of experts with both Grid Middleware/Applications and Network know- how (merging the 2 communities) Expensive idea, but useful: –bottleneck identification involve digging into both domains and its interface/interaction –Middleware and Application experts (VO,VRCs) could start excluding higher level issues in the ISO/OSI stack before NRENs and Federated EduPERT networking experts come in It turned out to be too expensive for the NGIs’ manpower/budget – at least at this stage

11. www.egi.eu EGI-InSPIRE RI-261323 11 Provided Answers on EGI PERT Answer n.4: Having a Global EGI PERT access point for users experiencing poor performances – forming a PERT Team with Grid-added know how – is useful, but we cannot commit any resource/manpower to it

12. www.egi.eu EGI-InSPIRE RI-261323 12 Scheduled Maintenances warned in advanceinformed asapWhen an identified accident or the scheduled maintenances of network devices/PoPs is impacting on a Grid resource center/site, users, site admins and Operations teams are warned in advance (Sched Maint) or informed asap (Accident) The idea would be inform users/site Admins about why things are not working when there are obvious reasons for experiencing problems – Currently GOCDB is used for Grid- related Sched M. Requires NREN-NGI communication/coordination: mapping between Network devices/PoPs and Grid resource centers/sites –a mapping between Network devices/PoPs and Grid resource centers/sites mapping between Grid resource centers/sites and Users –a mapping between Grid resource centers/sites and Users Can be managed using a pull or a push logic –Users subscribe to a given site and get notified –Impacted sites publish information on a web site and users fetch information from there

13. www.egi.eu EGI-InSPIRE RI-261323 13 Provided Answers on Scheduled Maintenances Answer n.3 Having a global EGI tool/service to warn users and site administrators about Sched Maint is useful; storing the information in one place is the solution to go for, but we cannot commit any manpower/resource to develop nor maintain such a tool

14. www.egi.eu EGI-InSPIRE RI-261323 14 Network TroubleShooting on Demand Grid site administrators, Operation Centers or authorized users experiencing problems in reaching a given site/resource perform troubleshooting on demand to exclude basic network issues behind the problems they’re experiencing Requires local deployment at the sites of probes controlled by a central system Results in the introduction of different roles Basic checks would involve ping, traceroute, reverse DNS checks, port scan, available bandwidth measurements

15. www.egi.eu EGI-InSPIRE RI-261323 15 Provided answers on Network Troubleshooting on Demand Answer n.3: Having a network tool for troubleshooting on Demand is useful, but we cannot commit any resource/manpower to contribute to develop nor test it

16. www.egi.eu EGI-InSPIRE RI-261323 16 e2e MultiDomain monitoring Users and Site Administrators get network performances measurements for a subset of e2e paths within the EGI Infrastructure, getting monitoring information gathered by scheduled, periodic measurements Muldidomain: NRENs, GEANT Monitoring data may include –Link Availability ( i/f utilization, Input Errors, Output Drops) –One-way Delay –RTT, number of hops –IPDV(Jitter) –Available TCP Bandwidth

17. www.egi.eu EGI-InSPIRE RI-261323 17 Provided answers on e2e multidomain monitoring Answer n.3: Having an e2e MultiDomain monitoring tool for a specific subset of of the whole set of e2e paths within EGI is useful, but we cannot commit resources nor manpower and cannot afford deploying anything locally at the sites

18. www.egi.eu EGI-InSPIRE RI-261323 18 DownCollector Users, Site Admins and Operation Centers need to check if services available at various grid sites are reachable and responsive DownCollector developed during EGEE for monitoring Grid services at the sites Migrated from EGEE ENOC to EGI Checks services are reachable on specific ports from a central location, star-based architecture Possible evolution would be to have additional geographically distributed instances, gathering results

19. www.egi.eu EGI-InSPIRE RI-261323 19 Provided answers on DownCollector Answer n.3: Having a DownCollector tool is useful but we cannot commit any manpower nor resources to contribute to its deployment

20. www.egi.eu EGI-InSPIRE RI-261323 20 Policy & Collaboration establish an EGI group of people, a body permanently in charge of interfacing the NRENs, EGI.eu, EMI, DANTE, GEANT and TERENA to discuss issues related to –the provisioning of network connectivity or the upgrade of existing links, –new services and new standards –new tools for monitoring, –new joint initiatives on tutorials, dissemination on tools, –testing and prototyping of middleware with respect to the network layer so that the requirements, coming from the EGI user community and the VRCs could be shipped to the Network community and relevant information is exchanged

21. www.egi.eu EGI-InSPIRE RI-261323 21 Provided Answers on Policy & Cooperation Answer n.2: Having a Policy and Cooperation Group is useless.

22. www.egi.eu EGI-InSPIRE RI-261323 22 How we structured today’s meeting 1. Introduction to the TF and its objectives 2. Report on what we propose for each use case 3. Presentation of tools 4. General Discussion/Feedback from NGIs –We should decide upon Approve a GGUS workflow –So that it can be implemented within the GGUS system Adopting or dropping the proposed tools Identify volunteering NGIs for early adoption, initial extended deployment of tools Identify possible missing bits or uncovered use cases/unsatisfied requirements to work upon