Re: agenda proposals for Prague

[Ronald van der Pol <Ronald.vanderPol@xxxxxxxx>]

On Thu, Aug 16, 2007 at 13:17:35 +0200, Ronald van der Pol wrote:

> For the upcoming GLIF technical meeting I would like to propose the
> following agenda items:
> 
> - interdomain monitoring
> We discussed perfSONAR last time. Several of us have been working with
> the E2EMON stuff for the LHC OPN. I will write down our experiences and
> the pros and cons of E2EMON and send it to this list soon.
> 
> During the meeting, I propose to agree on a set of requirements that
> we have for interdomain monitoring and see if E2EMON can meet them
> and what is missing.

This my current understanding of perfSONAR/E2EMON. Please feel free
to correct me or provide additional information.

E2EMON is part of the perfSONAR project. PerfSONAR is a distributed
monitoring framework. It consists of Measurement Points that give
monitoring information (e.g. RTT between systems). This information
is provided via web services. Historic monitoring information is
available via Measurement Archives.

Typically, each domain runs a Measurement Point. A monitoring webpage
can query all the Measurements Points and provide a overall end-to-end
view of the data. Each domain could run such a gathering website if
they choose to do so and if the Measurements Points give them access
to the Measurement Point data.

E2EMON is for monitoring lightpaths end-to-end. This is UP/DOWN
information only. A domain has to setup a Measurements Point. The
domain also has to create an XML file with information about all
the links. For each link, up or down status has to be measured
and reported.

The good points of E2EMON are:

Gives end-to-end UP/DOWN status of lightpaths.

It has user suppport. It is in use for the LHC OPN lightpaths. Dante
and several European NRNs use it for other projects/lightpaths too.

But there are also several shortcommings:

It is all manually configured. It takes a lot of time and coordination
with other sites to get the XML configuration files right.

For each monitored lightpath, a global end-to-end name must be
agreed upon.

Currently, there is only one website that shows the overall view
and this is password protected. This is quite useless for the
GOLE NOCs.

The table view is hard to read. It takes some time to understand what
is shown exactly.

E2EMON works with topology points. When there are several links
between these topology points, it it not clear how to distinguish
between them.

E2EMON only gives UP/DOWN information, no information about the
exact alarms, timeslot information, interfaces and equipment used,
etc.

For NetherLight, I am currently investigating if we can generate
the XML file automatically. Furthermore, I think we should setup
some requirements and "nice to haves" for a GLIF end-to-end 
monitoring systems. I also think we should work with the Network
Mark-up Language Working Group of the OGF. They are standardising
the XML format for network topologies.

> For a SURFnet project I am writing a document about our experiences
> with the "The ordering and fault resolution process for multi-domain
> Lightpaths across hybrid networks" document of Rene, Almar and Erik-Jan.
> I hope to finish a first version next week and will send it to this
> list.

I am still working on this.
> -- 
> 	Ronald van der Pol
> 	SARA High Performance Networking
>