perfsonar development work

[Mark Yampolskiy <>]

 Hi Freek, all,

thanks for the use cases, now it sounds more clear for us, what you are 
willing to achieve...

this issue is MANY-fold and have been raised by CNM-Team (Patricia and 
David, CC is added)
and former M&M (now M&W) many times in the last 4 years.
Therefore, IMO it is reasonable to make a joint working group to discuss 
and tackle these issues.

please find our comments in-line...

Am 07.09.2010 01:24, schrieb Freek Dijkstra:
> Hi Mark and Wolfgang,
>
> Let me try to explain a bit of the rationale and decisions we're
> currently thinking about.
>
> > in general, integration of multi-layer information is in the first line
> > not a technical but rather political/organisational issue.
> Out of curiousity, are there any particular political/organisational
> issues that needs to overcome? Right now, this does not stop us from
> going forward, but perhaps these issues can be tackled in a different
> "Gremium" at the same time.

have you ever tried to ask a network administrator to publish network 
topology, interface
specification or utilization? As soon as you not only just speak about, 
but ask admins to
export such information, this will collide with various domain specific 
security policies and
also personal unwillingness to do this and also (again domain specific) 
technical problems
to implement this.

> > - nobody from operations or managers says clearly "we need this", even if
> > they often say "it could be handy"
> Well, we need it. See the use cases below.
>
> > - usually there are multiple domain specific policies and/or security
> > considerations around, which prevent publishing of more detailed
> > information
> It seems to me that publishing more detailed information (the inverse of
> topology aggregation) is a different topic then multi-layer descriptions.

hmm... could be, that security policies are not as tight for such 
information - one never knows ;-)

> Right now, I prefer to focus on the technical aspects, though as you
> said, if there are any organisation demands that impact technical
> requirements, then I'm very willing to take those into consideration.
>
> > Good point is, that E2Emon can be (more
> > or less) easy extended to support multi-layer views, as it was originally
> > designed with such aspects in mind.
> Could you explain how you see multi-layer views added? I'm especially
> intrigued by your wording of "easy extension", as right now I do not yet
> see how this can be done without breaking backward compatibility.
>
> I do see how E2Emon can be used to describe a layer agnostic (or
> technology independent) view, as that is what it is doing right now.
> However, I don't see how it can describe the relations between different
> technology layers without requiring a modification to code in -at least-
> the vizualiser.

you are right, the _current_ version of E2Emon does not support more 
detailed information
or drill-down possibilities. However, M&M have written E2Emon in the 
way, which should allow
easy extension with _optional_ additional more detailed informations 
related to the logical
monitored links. This will however require
1) NMWG schema extension
2) extension of E2Emon to process the new information

a different (and IMO more flexible) solution for handling multi-layer 
and multi-tool integrated view
was proposed by DANTE and realized by CNM team. This solution consist of
1) Mapping schema should be define for correlation of different layers 
and metrics,
    which are provided by different existing (monitoring) tools. This 
mapping (or meta data) information
    should be provided by extra data source and can be defined highly 
scenario and/or connection specific.
2) Extra tool has to be developed, which uses mapping schema in order to 
integrate the existing data
    sources (without any changes) in a multi-layer view.
    CNM team has done this in LHCOPN Weathermap.
The advantage of this solution is full backwards compatibility, high 
modularity, possibility for parallel
development of different information sources.

> You asked why SARA wants to describe this. I can of course answer
> because we're part of GN3 JRA2 T3, but rather I present some use cases.
>
> A little background: SARA maintains multiple networks, including its own
> supercomputer network, which is connected to LHCOPN and DEISA, as well
> as the SURFnet6 network and the NetherLight optical exchange.
>
> Regardless of the monitoring function E2Emon, the driving factor in all
> cases is that we want to identify end-to-end circuits that cross
> multiple domains. For that reason, we advocate the use of global circuit
> identifiers (the globalName in E2Emon, or the urn:ogf:network
> identifiers in the GLIF community). If all announcements (being email
> announcements of planned work or an automated monitoring system like
> E2Emon) would use a globally unique identifier for a circuit, the lives
> of our engineers would be so much easier.
>
> That said, there are two distinct use cases where two or more different
> circuit identifiers need to be matched.
>
> The first is related to horizontal partitioning, on the same layer.
> A (now dismantled) circuit for the Phosporous project did run from
> London via Amsterdam to Prague.
> * DANTE used two circuit identifiers for the circuit in their GEANT2
> network:
>    #07017 for the part from London to NetherLight (Amsterdam) and
>    #07016 for the part from NetherLight (Amsterdam) to Prague.
> * SARA and SURFnet used a single identifier for this circuit:
>    #5030LE for the part from London to Prague.
>
> It would be useful to be able to relate those names. For example, if
> DANTE would announce that #07017 would go down, then we could ignore
> alarms on both #5030LE and #07016.
>
> The second use case is related to vertical partitioning, thus multi-layer.
> JIVE, the Joint Institute for VLBI in Europe has a gigabit Ethernet
> circuit, which they call "C5", which connects a radio telescope in
> Narrabi (Australia) with a hardware correlator in Dwingeloo
> (Netherlands). This circuit roughly runs from Narrabi - Sydney - Los
> Angelos - Seattle - New York - Amsterdam - Dwingeloo and is provided by
> many parties, including AARnet, CENIC, CANARIE and SURFnet. The CENIC
> service is provided by NLR (National LambraRail in the US).
>
> To be precise, CENIC takes care of the part between Sydney - Los Angelos
> - Seattle, and call this part of the circuit #AUS-SEA-5. The Sydney - LA
> part is (presumable) provided by some telco, while the Gigabit Ethernet
> circuit between LA - Seattle is a circuit consisting of 7 or 8 VC-4 over
> a OC-192 by NLR, called #NLR-LOSA-SEAT-O192, and these VC-4 channels are
> identified by the name #NLR-LOSA-SEAT-O192-258.
>
> The relationship between the different identifiers is important. It is
> not a simple matter that everyone uses a different identifier. For
> example, if there is a problem at NetherLight, CANARIE and CENIC see an
> impact, and need to be notified. However, NLR only provides a lower
> layer service to the Ethernet client layer and sees no impact, and
> therefor does not need to be notified. The other way is true: if NLR has
> a problem, NetherLight sees an impact.
>
> Such relations can also occur within a domain. In the same manner, the
> Gigabit Ethernet part between Amsterdam and Dwingeloo is in fact a VLAN
> on a WAN PHY Ehternet connection (thus using a OC192 channel), over a
> certain wavelenght, over a fiber. Each of these links has a different
> identifier, and is extended at a different range. The Fiber is divided
> in mutliple hops; the wavelength is between Amsterdam and Dwingeloo. The
> Ethernet VLANs are extended to CANARIE, while this particular VLAN is
> extended all the way to Australia.
>
> Three things are important here:
> 1) The link can carry multiple wavelengths, and the WAN PHY multiple
> VLANs. Each is a different circuit, with different end points. They need
> to be individually addressed.
> 2) The end points, and in fact neighbouring domains differ per layer.
> Consider this scenario:
>   +--------+                                     +--------+
>   |Ethernet| - - - - - - - - - - - - - - - - - - |Ethernet|
>   +--------+             +---------+             +--------+
>   |  SDH   | - - - - - - |   SDH   | - - - - - - |  SDH   |
>   +--------+             +---------+             +--------+
>    domain A               domain B                domain C
> What is the neighbour of domain A? Is that domain B or domain C? The
> answer of course that it differs per layer.
> 3) While domains A and C can of course describe each VLAN as an
> individual end-to-end link, domain B CAN NOT. After all, domain B does
> not know about Ethernet in the first place. In the example above, NLR
> may not know about Ethernet.
>
> I hope this explains a bit about the problems while describing multiple
> layers and why we're interested in making this multilayer extension.

yup, now your intention is much-much clearer

BTW, E2Emon already supports horizontal decomposition (e.g., multiple 
domain links in a single domain),
the drill-down of multi-layer is not supported, due to political reasons 
mentioned above.

you should also consider following two aspects:
- what is the EXACT purpose of the monitoring system with the 
multi-layer extension?
- how should it be integrated into multi-domain management processes?

cheers,
CNM team and M&W

> Regards,
> Freek Dijkstra
> SARA


--

======================================================================
Mark Yampolskiy                 E-Mail: 

Leibniz-Rechenzentrum (LRZ)     Tel.:   +49 (089) 35831-8742
Boltzmannstrasse 1              Web:    http://www.mnm-team.org/~yampol/
85748 Garching / Germany        Room:   I.2.107
======================================================================