Hi Roman e al-

In general, I think the NMLification of the NSI topology is quite good.   I do not mind the unidirectional aspects myself as I believe these are necessary for NSI (ultimately) anyway.  And as presented in Freek's example seem to be perfectly consistent with the current NSI model.    (FYI- I have  asked that unidirectional connections be a topic for NSI V2.0.

The vcard issue is not on the critical path for NSI, so I am not too worried about that.  Freek's suggestions seem fine to me.

There is some concern about using the "port" term itself as it is just so overloaded that it creates confusion.   But that said, I think the logical nature of the NML "port" construct as it represents STPs is consistent with NSI semantics.

I think the bidirectional nature of NSI STPs will relax soon as well to be unidirectional STPs.  STPs identify specific locations where a connection can be terminated (or originated).  And really, a unidirectional flow of data is the atomic element of a "connection" and is in fact how actual switching fabrics are actually constructed, so this fits best (IMO).  Binding arbitrary switch fabric input and output interfaces into a single "transmit/receive Port" on a box is purely an engineering practice (indeed - many optical equipment explicitly separate the transmit and receive paths to be configured independently by the transport engineers..)

Bi-directional Connections are [should be IMO] a compositional service feature. (see comments further down.)  There is no innate requirement that a "NSI Connection" be bi-directional.   Nor is it required that the forward and reverse components be congruent or symmetric.  Thus, I believe the basic coin of the realm should be a unidirectional topological construct as well.

I understand why Freek translated STPs to be the bidirectional ports - this is how the current NSI topology uses them. 
But I would concur that what we really want is a unidirectional concept of a domain edge interface (STP or port) that identifies uniquely the termini for service instances with an "orientation" - in or out relative to the domain.

some other comments below...
 
On 2/22/12 9:19 AM, Roman Łapacz wrote:
W dniu 2012-02-22 10:52, Freek Dijkstra pisze: 
Hi all,

I've tried to NML-ify the AutoGOLE topology. I did in RDF/XML because
that is probably readable by both OWL and XML folks.

Below are the steps I took in detail, along with intermediate results
(which may help in understanding the differences).

The main changes are:
- made ports and link unidirectional, per NML specs.
- use explicit link object to describe the SDP
  (NML has no connectedTo concept)
- change the urn:ogf:network identifiers to a valid syntax,
  the ones currently in AutoGOLE use are not valid according
  to proposed standard nor previous use in either GLIF or
  perfSONAR community.

The file AutoGOLE-Topo-2012-02-22.rdf gives the result so far.

Notes:

1. The resulting topology file has three layers:
  - NML topology
  - dtox NSNetwork
  - dtox NSA
  I really like the clear distinction between the data plane (NML) and
control plane (dtox/NSI). However, I wonder if we should move this to
two layers, perhaps merging dtox:NSNetwork and nml:topology.

I'm not sure of this distinction if nml:bidirectionalport is STP (I have a problem with this: dtox:hasSTP in dtox:NSNetwork points at nml:bidirectionalport; moving from dtox to nml domain does not look right to me in this case). All elements in the example belong to NSI abstraction (links are SDPs, ports STPs; except VCard part). To me distinction is between NSI topology (represented by STP, SDP, NSNetwork, NSA) and internal domain topology which is hidden under mapTo relation.
Yes.  But first things first.   This was/is a good exercise as we see that the NSI topology can indeed be represented semantically in the NML format.   This is a great first step.  

Now, as you suggest, there is this issue of "resolution" - the ability to define internal topology in finer resolution - still as NSI concepts or as NRM technology specific constructs.  IMO, we should be able to recursively define more internal detailed NSI constructs until the domain is ready to map the NSI constructs to the tuple that the internal NRM will recognize.   It is not strictly required that the "mapsTo" relation point to physical or technology specific information.  The mapsTo could map to a more detailed NSI topology internal to a domain (think of a "federation" NSI domains).   I do believe at some level the mapsTo should reference a topological object or tuple that is physical or a string that the local NRM can interpret to indicate where the NSI Connection should be terminated. 

Topo X1.  Perhaps a next exercise would be to stipulate a simple exemplar network with a single physical switch.     Lets take NetherLight domain as example.   The expressed NSI/NML Topology should be such that we can ascribe a simple  any-to-any switching function to NetherLight...from any ingress STP to any egress STP.

Topo X2a & X2b.  The next topology would be to enhance TopoX1 with the specification of an ethernet switch as Netherlight switching core.   For X2a, assume the switch can do VLAN re-write and so the any-to-any switching capability is maintained.   For X2b, assume the ethernet switch is a crufty old conventional switch that cannot swap VLAN IDs and so the any-to-any switching function is reduced to ingress port/STP(i) can switch to output port/STP(j) iff i=j.

TopoX3.   In this topo, provide an example we switch to NorthernLight.   Show how NorthernLight could present a single NSI domain but has NSI "sub-domains" in NYC and CPH.   (This is likely a real scenario...)   Assume the switching functions are any-to-any for all ports/STPs.   Consider the naming scope carefully.


btw. I'm still thinking that we don't need nml:bidirectionalport in NML :) We could use port with "bidirectional" relation.
I agree.   What is a "bidirectional port"?   It is really two ports bound together for purposes of ... what?  Indeed - Freek bound NSI STPs together as bidirectional ports...you didn't have any information that said these ports were even on the same switch or of the same technology!  (:-)  Be careful about what your assumptions are.   NSI STPs deliberately hide technology specifics - don't be fooled by the STP names:-)   There were no MapsTo relations that pointed to physical descriptions, so you all made some assumptions that were not necessarily valid.

A true "bidirectional port" would be a port on which data is sent in both directions simultaneously...which is in fact possible in the photonic realm.   So perhaps the "bidirectional port" grouping needs some further consideration?

Also... simply calling an in and out port a "bidirectional port" does not prevent those unidirectional components from linking to completely different far ends...  


Jerry
Roman

2. The dtox:hasSTP relation now points to a nml:bidirectionalport. NML
defines a similar "hasPort" relation between a nml:Topology and
nml:Port. (and there is some discussion to differentiate between
hasOutboundPort and hasInboundPort). If dtox:NSNetwork and nml:topology
are merged, I recommend to use these relations.
3. Yet unclear how exactly to tie Ethernet specifics to the examples, it
seems prudent to use labels and the subnetwork concept as discussed in
the NML-WG in Lyon (see subversion:
https://forge.ogf.org/svn/repos/nml-examples/20110922/other_examples/configured_vlan.xml;
you need a gridforge login. Drop me a line if you can't access it.)


Regards,
Freek Dijkstra


List of steps I took:

Source: AutoGOLE-Topo-2012-01-25.owl

Removed owl:NamedIndividual
Removed schema definitions (owl:Ontology, owl:AnnotationProperty, etc.)
Removed Position comments (used by auto-gole.appspot.com)
Removed unnecessary comments

Result: AutoGOLE-Topo-2012-01-25.rdf

Changed dtox:lat, dtox:long and dtox:Location to geo84:lat, geo84:long
and geo84:SpatialThing
Corrected label of Netherlight location from Copenhagen to Amsterdam
(geo84 was OK)

Changed dtox:STP to nml:bidirectionalport
Grouped ports of a single network in a nml:topology
Commented dtox:connectedTo, since this is not valid NML
Added rdfs:label to all NSA and all locations
Changed admin contact from string to vCard

Result: AutoGOLE-Topo-2012-02-20.rdf

Change urn:ogf:network identifiers to valid syntax
(urn:ogf:network:<FQDN>:<date>:<opaque>)
Make all bidirectional ports unidirectional
Explicitly defined NML links, with sources and sinks

Result: AutoGOLE-Topo-2012-02-22.rdf

Possible future direction:

Merge NML:topology with dtox:NSNetwork
Remove the dtox:managedBy property, as there is already an inverse
relation dtox:managing to find the correct dtox:NSA
Added switch matrix to each NML topology
Define switching capabilities for each topology.
use nml:hasPort instead of dtox:hasSTP

Result: (the-AutoGOLE-future-is-yet-to-be-written.rdf)


_______________________________________________
nml-wg mailing list
nml-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nml-wg




_______________________________________________
nml-wg mailing list
nml-wg@ogf.org
https://www.ogf.org/mailman/listinfo/nml-wg