perfsonar development work

Hi Freek, all,

in general, integration of multi-layer information is in the first line
not a technical but rather political/organisational issue. Such ideas have
been around for several years already, but always collided with two main
issues:
- nobody from operations or managers says clearly "we need this", even if
they often say "it could be handy"
- usually there are multiple domain specific policies and/or security
considerations around, which prevent publishing of more detailed
information

IMO, technical aspects can be only discussed, if the above mentioned
issues are solved. It couls also be that the organisational/political
reasons lead to various requirements/restrictions, which should be covered
by technical solution.
sorry for being a bit distructive. 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


please find answers to the questions inline...


> Hi all,
>
> In Geant3, we want to add cross-layer functionality to E2Emon. We're
> currently considering a few options, and have a few questions we like to
> get straightened up before we propose those options.
>
> For ease of discussion, here is an example topology information as
> served by our current E2Emon service.
> (see also e.g.
> http://cnmdev.lrz-muenchen.de/e2e/lhc/mon/G2_E2E_view_e2elink_CERN-TRIUMF-LHCOPN-001.html)
>
>  <?xml version="1.0" encoding="UTF-8"?>
>  <nmwg:message
>    xmlns:nmtl2="http://ggf.org/ns/nmwg/topology/l2/3.0/";
>    xmlns:nmwgtopo3="http://ggf.org/ns/nmwg/topology/base/3.0/";>
>  [...]
>    <nmwg:metadata id="metadata.11891256">
>      <nmwg:subject id="sub.8014380">
>        <nmtl2:link>
>          <nmtl2:name type="logical">
>            5004LE-asd001a_ome13-1-13-2</nmtl2:name>
>          <nmtl2:globalName type="logical">
>            CERN-TRIUMF-LHCOPN-001</nmtl2:globalName>
>          <nmtl2:type>ID_LinkPartialInfo</nmtl2:type>
>          <nmwgtopo3:node nodeIdRef="NETHERLIGHT-AMS">
>            <nmwgtopo3:role>demarcpoint</nmwgtopo3:role>
>          </nmwgtopo3:node>
>          <nmwgtopo3:node nodeIdRef="CANARIE-CHCG1OME2">
>            <nmwgtopo3:role>demarcpoint</nmwgtopo3:role>
>          </nmwgtopo3:node>
>        </nmtl2:link>
>      </nmwg:subject>
>    </nmwg:metadata>
>  [...]
>  </nmwg:message>
>
> Basically, this describes a port with attached link,
> "5004LE-asd001a_ome13-1-13-2", which is part of the end-to-end circuit
> "CERN-TRIUMF-LHCOPN-001". Furthermore, this link is between nodes
> NETHERLIGHT-AMS and CANARIE-CHCG1OME2.
>
> We have a few observations (or assumptions if you will). Can you confirm
> if those are correct?
>
> - The name "5004LE-asd001a_ome13-1-13-2" refers to the bidirectional
> link between NETHERLIGHT-AMS and CANARIE-CHCG1OME2, even though the
> peering domain would use another link description (in this case, CANARIE
> describes it as "CANARIE-TRIUMF-CERN_ChiNYC").
>

yes, this is correct

> - The links are matched based on the nodes (nodeIdRefs) and end-to-end
> path name (globalName).
>

yes, even if the tags used in NMWG does _not_ 100% match terms used in
system design ("nodeIdRefs" are IDs of nodes, "globalName" is the E2E Link
ID). Link to documentation you can find under
http://cnmdev.lrz-muenchen.de/e2e/lhc/mon/G2_E2E_index_PROD.html

> - The node names are supposed to refer to device names, not to domain
> names. Thus if the (name of a) node at a domain boundary chances, all
> peering domains must chance their description as well.
>

hmm... don't really understand, sorry
node "name" is what is referred as "Local Name" in GUI - this refer to a
_logical_ monitored link and not necessary to some devide. This name is
how NREN refer to the logical connection, it realize and monitor. How many
devices (DWDMs, Switches, ...) and physical connections are used to
realize the logical one - is hidden and can vary from domain to domain.

> - However, if the link name chance (e.g. because the interface chances)
> at a domain boundary, the peering domains need NOT to chance their
> descriptions.
>

again, how you name your logical name does not necessary influence the
physical realization (or vice versa)

> - It is possible to describe multiple channels over a single physical
> interface by describing each channel with a different logical name. For
> example, assume that the above link between NETHERLIGHT-AMS and
> CANARIE-CHCG1OME2 carries 2 channels, the link logical names could be
> 5004LE-asd001a_ome13-1-1"3-2-channel-1 and
> 5004LE-asd001a_ome13-1-13-2-channel-2. In this case, the peering domain
> must also describe each channel with the same end-to-end path name
> (globalName) and node names.
>

in the current version of E2Emon, virtual channels and trunks are not
supported. one E2E Link correspond to a singly physical (or logical -
depends on, what you are monitoring) channel.
There is a very rudimentary support for multiple connections between the
same end points - index at the end of an E2E Link ID. So you can define 3
links with IDs:
CERN-TRIUMF-LHCOPN-001
CERN-TRIUMF-LHCOPN-002
CERN-TRIUMF-LHCOPN-003

however, it says nothing about their physical location or whether some of
them are primary and some back up links. If you use virtual channels, I
would say that you need one E2E Link ID for a single channel.

> - The matching assumes that all LinkPartialInfo descriptions with one
> common nodeIdRef are connected (have a cross-connect) at that node. Thus
> a theoretical scenario where one would have two separate cross connects
> for the same end-to-end path in the same device can not be described in
> E2Emon (for a single layer this indeed makes no sense, for multiple
> layers, such "loops" may indeed exists, even though they are not still
> rare).
>

yup, only physical (or single logical) channel can be described atm.
if E2Emon should be extended for multi-layer support, we should consider
other use cases than just virtual channels


BTW, could you provide us a bit more info about SARA's use case for
multi-layer monitoring? many thanks in advance!


cheers,
Mark & Wolfgang (M&W)

> Regards,
> Freek Dijkstra and Peter Tavenier
> SARA
>