Skip to end of metadata
Go to start of metadata

(Out of cycle meeting to discuss VNOC, notifications)


(Default schedule is second Thursday of Month.)

0800 PT/0800 MST/1000 CT/1130 ET/1200 CT

Meeting Online Connections
Blue Jean s Meeting ID: 153579667

Meeting Recording:





  • Coordination of networking activities across LSST

Discussion items






0800Discussion Topics

By topic

Virtual NOC: 

VNOC requirements

(refer to LSST NET Meeting report section on VNOC)

Three aspects of VNOC information sharing
Maintenance notifications - Vincenzo Capone lead information collection/documentation
Fault detection/troubleshooting/recovery notifications - Albert Astudillo lead information collection/documentation
Performance monitoring - Julio Ibarra lead information collection/documentation

Two levels of notification/distribution:
1. within VNOC (network operators) THIS IS OUR CURRENT FOCUS
2. LSST operations centers (interpret above for LSST ops impacts) THIS NEEDS TO BE DEFINED WITH LSST OPS PEOPLE

Notifications for maintenance, outages, recovery
Email not reliable, need automation for scaling
IETF draft standard
AA, JI good draft, could use it, but let's see what operators currently do.
JK - If we standardize on this format, we will still need conventions for ID so that they can be understood by all (e.g. Object-ID)
RL - Someone will have to interpret what these messages, how do we get operators to produce notifications in this format?
AA - Open to doing, but must get agreement from operations
VC - GEANT uses internal system for ticketing/notification system, little possibility to change

Performance Monitoring
JP - PerfSonar is our common denominator. Produces transport capacity and latency. Need to see what else is exportable. Most data we collect and send out will be SNMP or perfSonar, maybe net flow, others. NETSage project is working on this.
MK - PerfSonar nodes need to be on same subnets/VLANs, dedicated to avoid noise from other traffic, applications.
RL - Need 100G NICs to support this.

Notification speed
RL - When fault/trouble, we need to know where problem is, NOCs know this but it takes a long time to find out. Need to speed this up for VNOC.
AA - REUNA sends initial message within 5 - 10 minutes after detection, then every 30 minutes until resolved
JI - This is complex space to quantify, with submarine cables it can be a while to report. Varies by service provider, easier where we have more control of network infrastructure.

Action items 

  • Albert Astudillo , Julio Ibarra , Matt Kollross , Vicenzo Capone - Impact analysis if we adopt IETF standard for VNOC.  Can you produce this format?  If not, what can you produce that could be transformed to this format? Look at all active resources supporting LSST, how to report in human-readable format  
  •  Julio Ibarra Define VNOC standard perfSonar/MadDash architecture (reuse existing documentation).  What are server configuration requirements, how to locate and configure VLAN(s)  
  • Julio Ibarra  Examine (NET)Sage framework relevance, assess IETF compatibility, other open source platforms that could be used to collect various operator format notifications and transform to VNOC standard format, and distribute  
  • Albert Astudillo Check if REUNA can host perfSonar node on LHN, publish to MadDash  
  • Ron Lambert Check if LSST Summit can host perfSonar node on LHN, publish to MadDash