[Nml-wg] NMLify of AutoGOLE topology

Jerry Sobieski jerry at nordu.net
Wed Feb 22 15:00:43 EST 2012

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 

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...

> 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 at ogf.org
>> https://www.ogf.org/mailman/listinfo/nml-wg
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120222/c013c082/attachment.html>

More information about the nml-wg mailing list